Variables in the address

[samkokajko]

So I'm not sure if I'm reading right that this is possible. Basically I'm building a form of monitor mixer. What I want to do is set a variable using a midi cc for what mix I want to control. Then another midi cc sets a variable for what channel. The address I need to end up with is something like /ch/01/mix/01/level

I have setup a midi cc to set variable 0 and 1 but can't seem to find where I can verify how it is storing that it a way to view the osc output to see what is happening. I just know it isn't doing anything on my console (x32)

The address I tried is /ch/<var0>/mix/<var1>/level

I also tried adding a 0 before the variable just to make sure it formats as "01" instead of just 1 but still no luck or change.

Hoping I don't have to hardcore 40 channels x 8 mixes

[camille]

Hi Sam,

The address you tried "/ch/<var0>/mix/<var1>/level" seems to work well for me, i.e. variables are correctly substituted.
You have of course to trigger your OSC Routing from a third input in order for OSCulator to construct the OSC address and send the message to the desired target.

You can do self-testing in many ways. For example you can open another window, and configure your OSC target to send messages to the other OSC input (e.g. 8001).


Best,
Cam

[samkokajko]

Hi Sam,

The address you tried "/ch/<var0>/mix/<var1>/level" seems to work well for me, i.e. variables are correctly substituted.
You have of course to trigger your OSC Routing from a third input in order for OSCulator to construct the OSC address and send the message to the desired target.

You can do self-testing in many ways. For example you can open another window, and configure your OSC target to send messages to the other OSC input (e.g. 8001).


Best,
Cam

Thanks for the tip on using 2 instances to test. So now my question is, is there a way to format the incoming data/the variable?

I went into scaling and changed it So that the osc scales from 0 to 127 so if I send a cc level of 4 my variable is 4. The only problem is it is 4.0 when ultimately I need to send it formatted as 04

Thanks for your help

[camille]

I am sorry, the solution I found is a bit contrieved, but here is how to can do (see attached example) :

- store MIDI messages as scaled values to variables.
- create a OSC Routing that will convert the variable 0 and variable 1 as two integer message arguments. It uses the "L" target so it sends the message to itself.
- use the result of this to construct address (instead of using <var0> and <var1> you must use <arg0> and <arg1>).

The result will not be formatted as 04 but merely 4, I hope this is not a problem.

[samkokajko]

Cast vars to integer.oscd

Ok here is what I got working using your formula.
Midi CC1 on channel 1 sets the channel, CC2 on MIDI channel 2 sets the mix bus.

MIDI CC6 triggers the send and adds the level argument. That then outputs to your "cast" address on L and strips everything down to integers as needed. Then in the output address of cast I was able to just add 0s in front as needed. I think what I will have to do is have a few instances of this and in Bome's MT send channels 1-9 to one set (with the padding 0 in the address) and channels 10+ to another set of routing that doesn't have the 0.

Actually thinking about it maybe this would be a good place for a preset. I could have Bome's send a message if the channel is greater than 9 that changes to another preset or just deactivates the padded 0 routing and enables a routing without the 0.

Is there a way to make sure this goes in the right order? (activate/preset and then process) I wouldn't want it to fire with the wrong routing and then activate the right routing right after it just fired.



Redundant/Backup plan: Perhaps in Bome's instead of sending a variable for the channel number I could send one for each digit of the channel number. So to express 04 I would send a variable 0 and a second variable 4.

Once I have these numbers in Osculator I should be able to do a lot of routing really simply using the same set of variables/arguments over and over

This is getting fun. I saw a comment you made about not knowing how to keep the interface clean and do translating to arguments and stuff but if you ever go that route I would be a huge supporter of it. I imagine I'm probably doing relatively weird stuff with the program though

[camille]

I think what I will have to do is have a few instances of this and in Bome's MT send channels 1-9 to one set (with the padding 0 in the address) and channels 10+ to another set of routing that doesn't have the 0.

Sorry to ask, but why is this leading 0 so important?
Could you share what OSC device you are sending these messages to?

Actually thinking about it maybe this would be a good place for a preset. I could have Bome's send a message if the channel is greater than 9 that changes to another preset or just deactivates the padded 0 routing and enables a routing without the 0.

Yes, but... meh. It sounds very complex just to deal with some padding.

Is there a way to make sure this goes in the right order? (activate/preset and then process) I wouldn't want it to fire with the wrong routing and then activate the right routing right after it just fired.

OSCulator fires events in the order it receives them.
Are you thinking of something else that could interfere with the initial order?

Redundant/Backup plan: Perhaps in Bome's instead of sending a variable for the channel number I could send one for each digit of the channel number. So to express 04 I would send a variable 0 and a second variable 4.

Yes, that would work, you just need more variables.
That's a creative use of variables and OSC routings

This is getting fun. I saw a comment you made about not knowing how to keep the interface clean and do translating to arguments and stuff but if you ever go that route I would be a huge supporter of it. I imagine I'm probably doing relatively weird stuff with the program though

Yeah, I like to explorer the possibilities of the software and see if we can extend them.
There is this fight between expressiveness/flexibility and simplicity, finding a balance is extremely difficult.
I try to keep OSCulator as simple as possible, even though it is way more complex than originally intended...


Best,
Cam