OSC Control

[Rulya]

David, about OSC commands for Playlist cue next and previous file I wrote, I think it will be usefull, and also to make in programme Master volume level and OSC commands for him. I mean in list we have for example tracks with 0dB, -4dB, -10dB - this must stay relative level, and Master level for all tracks, like we make volume in Window for output throw soundcard.

About OSC faders, command from them goes like on screen (from 0 to 100, decimal with point). I'm trying to make jogger for next and previous select cue, programme not understand this format(

[David]

Are you trying to select a specific cue, or just the previous / next one?

From post # 6 in this thread:

You can move the GO position with these commands (no spaces allowed for {cue}):
/select/first
/select/prev or /select/previous
/select/next
/select/last
/select/{cue}

[Rulya]

Are you trying to select a specific cue, or just the previous / next one?

From post # 6 in this thread:

You can move the GO position with these commands (no spaces allowed for {cue}):
/select/first
/select/prev or /select/previous
/select/next
/select/last
/select/{cue}

Yes, of cause! When you have a long cue list, I use this buttons to select to start, each tenth and end cue. Now in my list 141 cue. Quick selecting cues is good for repetition... And possibility to use an encoder wheel will be more comfortable.

[David]

The next release (v195) will have OSC commands for adjusting the volume, pan & speed of the currently selected cue in real time.
/cue/playhead/livevolumerel {integer amount to change it by}
/cue/playhead/livepanrel {integer amount to change it by}
/cue/playhead/livespeedrel {integer amount to change it by}

This is in addition to the current OSC commands for setting them to absolute values:
/cue/playhead/livevolume {absolute volume level: -60 to 0}
/cue/playhead/livepan {absolute pan value: -100 to 100}
/cue/playhead/livespeed {absolute speed value: 50 to 150}

You can also specify a cue by it's Q#
/cue/{Q#}/{command as above}

[jim10705]

So that I understand correctly...currently in v194 there are no osc commands (sent from remote app such as touchosc) for controlling volume?

[David]

The absolute ones (without the rel on the end) are in the current (v194) release.

Release 195 will add extra commands to adjust the level / pan / speed in a relative manner.

[jim10705]

thanks for confirming.  Which means I am doing something wrong in TouchOSC coding and need another pair of eyes:
I am trying to change the volume of the current playing cue but is not working.  I have tried various constructs of using sendOSC function call.  Below is the code in various ways attempted:

sendOSC("/cue/playhead/volume", -20)
sendOSC(
    {
    '/cue/playhead/volume',
      {
      { tag = 'i', value = -20 }  -- int
     
      }
    }
    )
sendOSC("/cue/playhead/volume -20")
sendOSC("/cue/playhead/volume, -20")
sendOSC("/cue/playhead/volume","-20")

Below is the touchosc log showing the osc messages sent:
SEND      | ENDPOINT(192.168.0.28:8090) ADDRESS(/cue/playhead/volume) FLOAT(-20)
SEND      | ENDPOINT(192.168.0.28:8090) ADDRESS(/cue/playhead/volume) INT32(-20)
SEND      | ENDPOINT(192.168.0.28:8090) ADDRESS(/cue/playhead/volume -20)
SEND      | ENDPOINT(192.168.0.28:8090) ADDRESS(/cue/playhead/volume, -20)
SEND      | ENDPOINT(192.168.0.28:8090) ADDRESS(/cue/playhead/volume) STRING(-20)

Attached is screenshot of how Multiplay is receiving and displaying the Preferences for OSC.

[David]

Sorry, that was my mistake. The commands are like so:

/cue/playhead/livevolume
/cue/playhead/livevolumerel
/cue/playhead/livepan
/cue/playhead/livepanrel
/cue/playhead/livespeed
/cue/playhead/livespeedrel

I missed out the "live" part when writing my earlier post. I've corrected them now.

The reason they are specified as "live" is that they don't affect the stored cue properties. They just control the specified value in real time as the cue is being played. The next time the cue is fired it will use the values from Cue Properties again.

[jim10705]

Works now 

[David]

I'm a bit torn on the OSC command names I've used for controlling the volume, pan and speed.

Maybe the "live" part needs to be dropped. I have it there to show that it doesn't affect the cue's stored parameters.

Being able to query the current volume, pan, speed would also be nice. Maybe if no argument is supplied in the OSC command it should return the current value. If so I guess it would be as another OSC message?

The syntax for nudging values up and down could also be better. The added "rel" in the command seems clunky. Would something like this be clearer?

Query the current volume (OSC message in return?):
/cue/playhead/volume {no parameter}

Set the volume to an absolute value:
/cue/playhead/volume {dB value (-60 to 0)}

Increase the volume by the specified amount:
/cue/playhead/volume/+ {dB value (1 to 60), or use the value in preferences if none specified}

Decrease the volume by the specified amount:
/cue/playhead/volume/- {dB value (1 to 60), or use the value in preferences if none specified}

That looks cleaner and probably easier to expand later for other parameters. Using + and - seems sensible.

It could possibly be extended to allow resetting of the parameter to the one stored in Cue Properties like so:
/cue/playhead/volume/reset
or maybe:
/cue/playhead/volume/revert

The same syntax would work for pan and speed.

[David]

I've just coded some of this now and it's much nicer to create and maintain.

It also opens up other possibilities for OSC control commands.

[jim10705]

Understand your concern about naming conventions and "hindsight is 20/20 vision".
I'll adjust my code to whatever is decided.
I like the idea that MP receiving OSC message without an argument (where one is normally expected. Or with "?" in place of expected argument) means that MP should respond with the current value.  There would need to be disambiguous syntax for every possible osc message, so that it is clear what each form means and how MP should act and respond.  For example, an osc message without an argument means use the default in preferences versus the remote is querying for the current value and not make a change. Unless each osc message syntax is distinct.

It would be nice in certain situations for MP to send the volume at which an audio cue was started at same time as the status GO (clicked). Also when it sends the playhead cue position (of what would be started).  If that makes sense  :-)

[jim10705]

Geez, this reminds of the days when I did software programming in Smalltalk and Rational Rose (that'll show my age!) and figuring out getters/setters, class/instance methods and overloading. 

[David]

I was originally thinking that any OSC replies would go to the IP address and port specified in Preferences > OSC Control > Remote (Outgoing), but maybe not.

When an OSC command is received by MultiPlay, the IP address and port number of the remote program is also available. If the reply is sent using those details, it would mean that you could have more than one remote program requesting data from MultiPlay and they'd all get the data they asked for.

As for how multiple remotes would be sent the status data (current cue, etc) I'm not sure of yet. MultiPlay could even show a list of recently active remotes, each with their IP address and port number.

[mariano1234567]

Works now 

Hello everyone! and thanks David for this incredible program! I'm working on integrating OSC and NodeRed for some automations that I need for my theater production, and I'm having trouble getting the livevolume to work... jim10705, how did you manage it?
I mean, which of all these options you mention worked for you?
and, it's supposed to work /cue/{Q#}/playhead/livevolume ?

And David, when will version 195 be available? I'm eager to try it out!