

That simple protocol is very easy to test, use and Take simple commands like "pl" for play, or "st" for still (each justįollowed by cr/lf). Messages, back to the days of the Pioneer Laser Disc player, which would I've long been a fan of simple, human-typeable, ASCII based control I guess the key part of your phrase is that one "machine" can controlĪnother :-) Of course, for a human to send "go" from any program thatĭoesn't have OSC support they'd have to type /go!00!00,!0A!0D :-) > The fact that one machine can control another one by sending a "/go" OSC message is, in my view, pretty darn simple network-based remote control. Thus, the whole address is a string, and the string includes a portion that is interpreted as a cue number in QLab. In this case the cue number is part of the address of the OSC method, as that's the OSC-ish way to address an object in the program. In QLab the cue number can be any string, to support things like letter "numbers". The cue "number" is, as you guess, a string. I'm assuming in my example command that it's ASCII, since there are so many potential cue number formats (even-god forbid-letter cues :-) )? It looks from the API where it shows "/cue//start that the cue number would not be a separate argument, and instead is part of the method, but maybe it should be an argument instead? > I'm sure I'm missing something obvious, but I also couldn't find in your OSC API any mention of what the cue number format is. > Now I tried to fire a specific cue, and I got stuck again. > will fire the next cue in the current workspace. Thanks to your tip about the console logging, I'm able to get an "unable to parse OSC method address" whenever there's a problem, and I tested a bunch of options and it needed all of these parts to work. The 0A and 0D is the 'ol carriage return/line feed. The "," is there to indicate that there are no "arguments" to this "method". > The null (!00) is there to indicate the end of the "version" string, and must round out the string to a total byte count (not including the "/") evenly divisible by four ("version" has seven characters). > So, to send the "Version" command (the simplest one, it seemed to me), you have to actually send (where the "!" indicates to Medialon Manager to send the associated hex value of non-alphanumeric ASCII characters): > You were right-I forgot the null padding, and also left out the argument type tag indicator. Let me know if I can help troubleshoot further. Hopefully the above logging output provides a lead. (In OSC everything is null-terminated and a multiple of 4 bytes.) I'm sure you're already aware of that, just figured I'd mention it as something to double check. One potential hazard in writing the commands directly in raw ASCII is the necessity of padding various fields to multiples of 4 bytes.

16:32:26.811 QLab sent OSC message: /cue/1/colorName green If you are using 3.0.6, there is another option to turn on even more debug logging.ĭefaults write .3 debugIncomingOSC -bool YES You can review these log messages using the /Applications/Utilities/Console.appįor example, the "/cue/1/start" message would produce something like: If you go to QLab -> Preferences -> Logging Level: 2 you will get log messages associated with the incoming OSC messages.
