In Part 1 of this series, I laid out how my thinking has changed in terms of how to control things on a show. I had been a strong advocate for universal control protocols, but now I actually favor customized solutions based on the near-universal data transport solutions of IP and Ethernet, and in this entry I'll lay out why I've been thinking about this lately, and why I now think customized solutions are better.
We started the Gravesend Inn haunted hotel in 1999 (if you live in NYC you have only two more weekends to see it!) with a Conductor show controller. In those years, networks were still costly and had some significant drawbacks, so we controlled things with direct contact closures going into the show control hardware, serial connections, MIDI and MIDI Show Control (MSC). As technology has become more powerful and affordable, our haunted hotel control system has evolved into a sophisticated network-based system. And this year, with the release of Stage Research's SFX V6 and its new network features, I've been able to easily move one more major show system away from the constraints of MIDI Show Control and into a customized, IP-based solution.
SFX version 6 has a scripting language at its core, which allows sophisticated conditional operations to be implemented into its shows. Fortunately, SFX also accepts these scripting commands over the network, and the Medialon Manager show control development environment has a software device called "Low Level Communicator" (LLC) (related press release here) which allows users to implement their own device control schemes pretty quickly and easily. So, configuring Manager to talk with the SFX System was simply a matter of entering the target SFX system's IP address and its port:
I connected the two computers using an Ethernet switch and two Cat 5 cables, set the IP addresses, started Manager and, voila!, Manager's status variable for SFX showed "Connected". Success!
Next, I just had to write some commands into Manager so that I could easily build these as cues into sequences for the show. I entered the information for the basic GO command and it worked the first time. This Go command would be all that would be needed for a simple theatrical show, with only one cue list in the SFX system. But for the haunted hotel, we needed SFX's "GO LIST" command, which allows a cue in a specific cue list to be triggered, since on the haunted hotel we are running, basically, a dozen or so separate independent shows, and we build each area with its own cue list (or lists) in SFX. Getting this GO LIST command working took a bit of futzing since the documentation didn't indicate that the SFX List ID had to be surrounded by quotes.
To implement, test, and debug this whole thing took me maybe an hour or so (granted, I've been doing this for a long time). And it wouldn't take you that long since I posted my LLC file on the Medialon site. I'm sure that SFX 6 still takes MIDI Show Control commands, and I certainly could have just used last year's haunted hotel program, and it probably would have all worked just fine out of the box. But then, I wouldn't have gotten a couple of very nice features for "free".
I am terrible at remembering numbers, so when controlling the older SFX version 5 using MSC, I would always have to have a piece of paper around to remind me, for example, that the Tipsy's Parlor's sound effects were contained in a list permanently ID'd by SFX V5 as "F", which would be controlled using MSC cue list number 6. (The worst thing was in SFX V5 is that if you closed cue list 1, all the list ID numbers would decrement by 1, meaning everything would fire wrong!) With a user-configurable, text-based List ID (a great new feature of SFX V6), we were able to come up with our own names or ID's for each list. Since we already had three-letter codes for each area designated for our cabling database we simply used them for list ID's to keep everything simple. For example, you can see here GO LIST "TPR" Q 1, which fires a cue in "Tipsy's Parlour" (otherwise known to our crew as the "upside down room"):
(The !0A!0D is a carriage return/line feed combination in hex (the ! indicates to manager that the next two characters indicate a hex byte) and I didn't spend the time to suppress them in the display.)
This approach made our time during programming a lot easier, and eliminated many errors.
Feedback and status reporting is another very cool "free" feature of this kind of control: In the graphic above, you can see a status of "Opened", and that text is actually coming back from SFX telling us that the network communications socket has been opened successfully and is ready to accept commands from an outside source. And it's trivial to display that status on the Manager user screen (see blog entry here to see the overall user screen). And the status can give us other information as well. Several years ago, I built into the Manager code the ability to enable and disable several systems: Mechanical, Lighting and Sound. In this way, if sound is not ready or needs to work offline, we can disable sound and continue to work on lighting. To do this, I simply used a Manager command which enables or disables the virtual "devices" which represent the real controlled devices in the system. And I discovered that when I used this enable/disable functionality, Manager and SFX automatically close the network socket and, even better, gives feedback about that too:
So now, right from the main show controller, we can verify not only that the two SFX computers (one is in the basement, far from the control room) are online and functioning, but that the SFX software is actually alive and communicating. This is very cool and useful feedback feature, and cost me programming time of...virtually nothing. On the other hand, to implement this kind of closed-loop feedback using MIDI Show Control, I would have to implement two MIDI connections (one each direction), and then send an MSC command to a cue in the target system which would then send a MSC message back to the show controller, which would then do something that would give some sort of status indication.
And the exciting thing is that with something as smartly and flexibly programmed as SFX version 6, we are now just at the beginning of what's possible. Want to fire a complex sequence in SFX? No problem, just add a command into the LLC file. Want to set a variable in SFX? Same thing. Want SFX to set a variable in Manager? No problem. This is the cool part about customized, optimized control.
So now everything in the Gravesend Inn is controlled over the network, except a Yamaha DM1000 audio mixer, which uses standard, musical MIDI; the Whole Hog II, which only accepts MSC; and then two very old video switchers which take only serial commands. And having so many things on the network offers some very cool additional features for "free". For example, this year, we added a new boiler effect, which is in the basement far from the show control screen. To test the mechanical effects on the boiler, I would have to send someone down with a radio and see if what I do on the Medialon system is controlling what I think its controlling (I know, I could run Windows remote desktop wirelessly or something, but that's a hassle, the wireless wouldn't likely have reached into that location in the basement, and it would be a bit scary having that much crazy Microsoft stuff flying around my network). Instead, since I'm using Ethernet I/O units made by Advantech , I simply went to the nearest computer on our (closed, private) network, and typed the IP address of the I/O unit into the URL of a browser window. The unit actually serve up a Java-driven web page; enter a password, and up pops this screen:
So, from any computer on the network, I can monitor the sensor inputs and also control the outputs simply by clicking the onscreen button (of course, you have to be very careful with this). One other benefit of having so many things on the network is that the computer that runs the whole system now has no local hardware at all-the only connection to the outside world from the show control machine is a single Ethernet cable which we have connected to a Gigabit switch (The MSC to the Hog II is delivered over the network using a MIDI KISS Box, and the MIDI to the DM1000 is fired from a local MIDI interface connected to the video controller (another Manager system)). This means that constructing a backup system is pretty easy and requires no computer hardware installation (the KISS box needs its drivers installed, which takes quite a few steps). This is very, very cool, especially in conjunction with other benefits like the "reliable" connection offered by TCP, and the built in CRC error checking offered as part of Ethernet which ensures that control messages will be delivered in tact (if any of these terms are confusing, of course, I know a good book you can buy to explain everything).
As I write this (on the plane to LDI in Vegas), the entire system has been running for a few weeks, and it's been rock solid and far easier to deal with than any other system we've ever used. MIDI, serial, etc offer a bit more simple control, and may be a bit easier to learn and understand. But modern network control is actually cheaper from a hardware perspective. To connect Medialon to SFX using MIDI, I would need two USB MIDI interfaces, and two cables. That would total up to far more expense, with far less return, than a decent network switch and two Cat 5 cables. And as for time, I would argue that spending the time to learn how to control things over the network is an investment you will not regret.