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). 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. 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. 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). 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. 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 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. 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). 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). 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. 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). My primary case for simple ASCII-based control messages came down to this: 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. (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") ) 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. 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, it needs its messages padded out to multiples of four octets, and you have to handle arguments for messages in a specific way, etc. OSC, though, is kind of complicated overkill for the kinds of simple ASCII-based control I prefer and have written about before. 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. 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.
0 Comments
Leave a Reply. |