Controlling QLab V3 Via OSC-Like ASCII Commands From Medialon Manager

The release of Version 3 of the widely-used, Mac-based sound effects playback program QLab from Figure 53 brought with it something I've been waiting for for a long time: controllability over IP. Figure 53 implemented Open Sound Control (OSC), which is a great protocol for things like fetching and managing lists of cues for the QLab remote control IPad app.  OSC, though, is kind of complicated overkill for the kinds of simple ASCII-based control I prefer and have written about before. For example, it needs its messages padded out to multiples of four octets, and you have to handle arguments for messages in a specific way, etc.  None of this is a big deal for a computer to handle, but it makes the construction by humans of simple strings for control kind of complicated. For example, to tell QLab to Go on the next cue in the workspace using OSC, you would have to send "/go 0x00 0x00, 0x0A 0x0D" The /go is the main OSC "address", the null octets (0x00) are there to pad out the address name to the required multiple of four octets, the "," character is the start of arguments for this address (there aren't any for this address), and then the 0A and 0D are Carriage Return/Line Feed.  (Medialon's Eric Cantrell figured out how to automatically frame an OSC "Go" message with this syntax: Manager (OSC_String_to_Send = "/cue/" + QNumberString + "/start" + ("!00" * (5-Length(QNumberString))) + ",!00!00!00!0A!0D") )

I went back and forth about this in a fascinating exchange with Figure 53's founder and lead developer, Christopher Ashworth; you can read the whole thing here.  My primary case for simple ASCII-based control messages came down to this:

I've long been a fan of simple, human-typeable, ASCII based control messages, back to the days of the Pioneer Laser Disc player, which would take simple commands like "pl" for play, or "st" for still (each just followed by cr/lf). That simple protocol is very easy to test, use and program, and was a big improvement, from my perspective, over things like the then common Sony 9 Pin control scheme, a three byte binary message with a check sum. And that kind of simple human typeable control is still common today; here's an animatronic controller I just got firing from Medialon Manager last week (I'm doing a lot of haunted house upgrades this summer). And a lot

of systems these days basically just accept their internal scripting language controls over an IP port (these two systems--SFX and GrandMa2--have been running lighting and sound for our haunted house this way for the last few years).

I expanded on this in a later message: 

I actually teach undergrad students in my (required, basic) Entertainment Controls Class to type ASCII messages back and forth to each other, first using open-source Teraterm over serial, and then Essential Net Tools over a little network. The students usually start out a bit confused, but by the end of the lab they are usually sending jokes to everyone over UDP broadcast. I find it to be a really good way to explain what goes over the cable (I know I learn best by seeing this stuff in action), and to make it all a bit less abstract (always important for show biz students), since they can get the idea that "characters" on the wire are really just voltages on and off, coded to the binary values of the ASCII.

They then move onto controlling a piece of gear using simple ASCII commands (currently, an old Pioneer DVD player but I'm planning on upgrading that soon). Of course, they would never run a show this way, but it's important for them to understand how this kind of simple control works, and if you can use some sort of terminal program to debug out a working string that does something, then you can just cut and paste that string into whatever program you want to do the control, et voila! :-) In show control class, some of the more advanced students can use things like Medialon Manager to take that string and then embed a variable name where the working Q number was, and then they can do pretty sophisticated stuff with that simple setup.

I guess there's some invisible line of complexity that gets crossed with OSC for me with the abstraction in the objects (I only took C back in the day and never C++ so I'm always on thin ice any time I use the word "object" around real developers), and also the byte padding. Stuff like that means that you really need to have a pretty significant coding background to even comprehend the basic interchange process, and two strings that do the exact same thing "Go Q123" and "Go Q1234" actually would not be just one byte different ("123 0x00" vs "1234 0x00 0x00 0x00 0x00") That's a tough thing to explain to most of our students, who have only one required programming class (typically in Processing). Even for me, I had to go to Wikipedia and read up on the C string termination stuff to even get started with OSC.

Eventually, I did get QLab firing OSC from Medialon Manager, and then Mr. Ashworth surprised us on the QLab mailing list with this:

Alright, I couldn't resist:

Turns out it took about 15 minutes to add the ability to accept simple ASCII strings over UDP port 53535.

These strings are interpreted as OSC commands, precisely as QLab interprets the "raw" commands you can enter into an OSC Cue.

Thus, you can send OSC to QLab without sending OSC to QLab.

Examples:

echo "/cue/9/start" >/dev/udp/localhost/53535
echo "/cue/1/colorName blue" >/dev/udp/localhost/53535

echo "/cue/1/effectSet Saturation 0.2" > /dev/udp/localhost/53535

This is very cool!  I wrote a little Medialon Manager program to test this out, and it works great: 

You can download this Medialon Manager program here; the low-level communicator driver is available here.  I beat up on QLab from this program as much as I could, and it looks rock solid.  My only suggestion for the future for QLab's pseudo-OSC is that QLab would adds some sort of response to the message so that we can easily close the loop.