How Do I Apply Qlab to Rafter in Theater?

Someone landed here using the above as a search term. I am intrigued. I wonder what it was they were trying to find, and if anything I wrote was any help at all. (That particular search seems to turn up mostly references to James Bond computer games...!)

What would Qlab do with a rafter? Or would it be ON a rafter? Since it is software, it can't "be" anywhere by itself, but you could certainly stick it on a Mac Mini and stick that in the rafters. I've seen workplaces with Mac Minis tucked behind display screens running video loops.

Qlab isn't just sound playback software. It will also play back videos. And it will also generate MIDI events. I know, I know; MIDI is old school. OSC gives you more detailed control and is the current choice among experimental musicians.

But MIDI is out there. There are control surfaces (such as, the Korg nano series -- I have seen video of a Korg nano-slider being used to control remote cameras in real time) Or the Behringer BCF2000, a motorized 8-fader control surface, that are already capable of communicating via MIDI.

There are lighting consoles (and some automated fixtures) that already speak MIDI. On a dance show a little while back we ran the entire show from Qlab, and while each music track was playing multiple Qlab auto-follow cues spat out MIDI Show Control commands to the lighting console, calling up non-sequential access lighting looks.

And when you include MIDI Show Control, there are motor controllers that respond to MIDI. So Qlab could actually do something to a rafter.




On the flip side of the interaction, I prefer using MIDI surfaces to control Qlab, as MIDI "Go" and "Stop" commands will execute regardless of where the cursor is or if Qlab is even focused. A Korg nano-key has been good for that; I double-stick tape it to the top of the sound board and mark off the "Go" and "rewind" keys with board tape and Sharpie.

My nanokey, looking a little battered.

I hasten to add that Sound Cue Systems and SFX also have these abilities, plus there are some other tricky ways you can get the same kinds of interactions with other software or even hardware options (I've done more than one show with an old Roland "Doctor Sampler.")

It is when you geek out a little, though, that things really open up. MIDI is, as a language, quite simple and robust, and so is the physical layer. As one example of designing a new physical layer, a single resistor is all you need to get an Arduino micro-controller to spit out not-quite-standard, but still quite readable MIDI. I have yet to find a device that my Arduinos have been unable to talk to.

A couple more components (in the schematic I've been using, a diode, an opto-isolator, and a couple of resistors) allows the Arduino to receive MIDI via its serial port (I haven't yet tried this with Soft Serial but I have good reason to believe it may work.) It also may be possible for an Arduino to emulate USB well enough to fool a computer into accepting a MIDI signal via USB. There are better solutions, however, to this particular physical connection!

Here's the simple MIDI-in schematic:

From carcat's Instructable

Using simple software like Processing, you can write little translators that will act as go-betweens for serial devices, HID (like mice and keyboards), and internal and external MIDI ports. The simplest form of this is to take a serial data input (such as the Arduino, which shows up as a COM port), and translate the serial stream into internal bus MIDI which Qlab will then read and act upon.

Or reverse the sequence; have Qlab's output translated into serial or USB output which then drives a relay board.

I prefer using MIDI for the intermediary myself because I like the self-documenting aspect of that physical layer. You know which devices will respond because they are physically connected with MIDI cables, and the correspondences can all be made linear and logical; instead of having the first relay be "fred" and the second relay be "ethel" and you've forgotten what name the third relay answers to, you know you always start with MIDI note number 1, so all you have to do is count up.



So far, practically, all I have done is used MIDI and micros to trigger sound effects from Qlab. Although I have connected both Qlab and SCS with a lighting console, Qlab has almost always been the slave in the chain; the lighting console has sent the MIDI command that keeps Qlab's sound events timing-locked to the console's lighting events.

I finally have a MIDI-controlled servo lying around that I could drop into a show that needed it. Up until now, the only gadget I've had in that ready-to-go form has been my remote buttons. And they are overdue for Version 3.0; for longer range RF, for user feedback, etc.

The MIDI-controlled projector douser -- or, rather, a MIDI-controlled servo.

The douser has a MIDI in port, a bicolor status LED, a DC power jack (for a wall-wart, sigh), and a 1/4" jack for controlling it with a simple on/off switch.

This is the current version of my MIDI-in button. The terminal strip is for inputs, a MIDI-out port is on one side, and USB programming/power port on the bottom.

For the picture, it was being powered from my Minty Boost; a 5V USB power supply in an Altoids tin. (Kit from Lady Ada.)

Unfortunately, even though the current box can be powered from, and programmed over, USB, it can't send MIDI through USB. So added to the tangle of wires is an M-Audio MIDI-to-USB interface.





My current tinker project is a dedicated Qlab control surface. I think I've finally found the best chip to use; an Atmega32u4 on a breakout board sold by Adafruit. The chip is one of ATmel's USB-capable AVR chips; just attach the connector and it is a class-compliant USB device out of the box. Using the LUFA library I should be able to make a USB-powered MIDI controller surface. I have a small flat project box purchased for the project, with some big clicky buttons on it.

Of course, since the linking of MIDI events to Qlab operations happens in the Qlab preferences, if the device is set to raw MIDI it could be used for anything...even as a very short keyboard.

Alternatively, I might program it to spit out MSC instead, which is hardwired to Qlab's playback commands.

The biggest problem I'm having with the device is feature creep. There's plenty of space to include some jacks to drive a remote button or two, for instance. And I've used this enough times that I should probably make it available.

My latest version of the physical layout is to make the jacks 1/4"TRS. The upside is a smaller footprint on the back of the device, meaning you can fit them in easier. They are also simpler to mount -- and a lot less annoying than the dangly XLR tails I have on my current version of the box.

The downside is needing lots of TRS to XLR adaptors to run the signal from the remote buttons or sensors through the existing theater wiring. In any case, having three conductors available means I can add status lights to the remote units; they would light up when they "saw" the base station, and with a little more cleverness might even change color when the base station reported it had received a go command (this would tie up three digital I/O pins, though.)

It is also tempting to try to shove an Xbee module, or a 915kHz radio, to permit use of wireless remotes.

That is also something I need to find time for. My current wireless has mostly been useful for checking monitor speaker, although I did use it for a gunshot effect in one play.

The RF-MIDI remote shield, currently without a spare Arduino to host it.

My dream is to make a small robust transmitter that is as plug-and-play as my current remote wired button. The likely form factor is not a keychain remote, but more like a cigarette-pack case with internal battery and a jack for the sensor. The sensor options would include a Hall-effect switch or an opto-interrupter that could be non-destructively retro-fitted to a prop gun in a couple of minutes, allowing that prop to then remotely trigger sound effects.

(As well as lighting effects, physical effects, pyrotechnics; once the signal is in the digital domain not even the sky is the limit.)