Arduino working backstage

I've been using Arduino in conjunction with the sound playback software Qlab, in live theater. Communication has been over MIDI, using the simple hack of the Arduino's serial port as a non-class-compliant MIDI out.

In a current show, the Stage Manager has a "Go" button, and the computer for playback of sound cues is across the booth. Besides getting a big, debounced button that doesn't take up a lot of desk space, it also means Qlab will fire the cues whether it is focused or not.

In a couple of previous shows, I ran a second button through snake or house microphone wires all the way back to orchestra pit so conductor or percussionist could fire off a sound in tempo with the music.

In one show, I used Qlab as a primitive software sampler; an "intercom" button onstage operated by the actor played a buzzer sample from the sound computer as long as it was held down. Then the sound operator in the booth would hit a second button to fire off a pre-recorded voice-over-the-intercom cue (or a backstage microphone, rigged to the same on-stage speaker).

The advantage to going over the sound playback computer, instead of a sampler or similar, is that we can tweak the sound file, and it plays back multi-track, assigned across possible multiple speakers located all around the stage. So instead of being stuck with where a doorbell or live telephone was physically wired, I can play and tweak the sound to whatever works best within the total sound picture -- and tweak it right up to opening night.

I love that I can wire any switch contact or sensor, route it through whatever wires are available in the building, and debounce it and condition it as necessary in software.

And on the Arduino side, a few minutes with a laptop is enough to tweak the code to send MIDI noteOn and noteOff events, or even MSC (MIDI Show Control) Go and Stop commands.

My future plans -- when I get some free time! -- are a dedicated controller surface with big tactile "Go" and "Stop" and "Rewind" buttons -- a cell-phone sized controller pad I can put anywhere where it is reachable but out of way of scripts and so forth.

And also to explore options for spitting MIDI to computer without needing a USB interface; either USB port, or host-side software interpreting a straight serial out.

Since many sound boards and light boards speak MIDI as well, I can use the current Arduino box independently. Since I built my second MintyBoost, the battery lasts for days, too.

Sounds interesting, maybe you could also generalise the project, so you don't have to keep changing your script. Produce some kind of simplified instructions that you can send to the Arduino over Serial that it then tucks away into EEPROM?

Don't forget about Xbee radios. They could eliminate having to run more wires. Cool idea, makes me wish I was still running the lights in a theater!

In re the first, my thought has been to add a dip switch. Right now since it is just me using it, and I'm powering it off of/connecting to a laptop anyhow, it is no bother to tinker with the code.

I did use it with a 433 kHz keyfob remote. Actually, one show I had an actor with a prop gun hiding the keyfob in his other hand, and using that to trigger the gunshot sound. The range was so poor, though, that I've now bought an xBee starter kit to play with instead.

If you need RF control, are you aware of the Jee Labs "Jeenode"? This is an arduino-compatible board (software-wise, at least) using a AT328, and the board also has a 915 MHz data radio built-in. I have not used one so I don't know what the effective range is, but it is pretty small and pretty cheap! The kit is under $25.

See also:

NOTE: according to this post, informal testing shows indoor range of "150 feet, through three or four walls maybe". (However, the ISM license-free bands are crowded. If you are in a very busy area, I suppose you might get enough interference to effectively have no range at all.)

That jeenode looks promising. I've still got wireless microphones in those bands, though, and adding more RF hash to what is already there is a bit of a scary thought.

One of my random thoughts was to use xbee in a net topology, so no transceiver was tasked to make the entire distance from stage to booth by itself. But that seems to predicate on having a lot more applications on stage that deserve nodes.

In practical terms, I'm mostly working old standard plays and musicals. For some sort of experimental dance/music/performance thing there are all sorts of exciting possibilities, but for straight theater...

The thing is, theater has an existing and robust system to tie electronic events to on-stage action. That is, the framework of scripted cues, stage manager, and live operators with their eyes on the stage. The usual development of an effect through the technical process is optimized towards manual execution -- it is at this point in the history of technical theater more difficult to introduce an automated effect into that process.

The direction my ideas have been going in is towards "sweetening." Theater environments are false, the construction materials often wood, the props non-functional. It would enhance the reality if many of the sounds (and in some cases, lights) could be subtly overlaid by more realistic sounds or effects.

Way back when I manually triggered a stone scraping sound when Fagin loosened a brick in his fireplace to take out his hidden treasure. In a much later production, I was tempted to cue a thunderous "bang!" when the Beadle stamped his staff of office on the ground. In one production, it would have been very cute to be able to automatically follow an on-stage, hand-held candle with motivators (aka the lights from the grid that are actually lighting the scene).

The key I think is looking not for what things COULD be automated, but what things NEED to be automated because a human operator can not get the timing accurate enough; such as playing a gunshot sound effect in synchronization with a prop gun.

But the flip side is that the old methods are very well understood and reliable. So if you are going to introduce electronics into the mix, it has to be reliable, and operator-transparent (most running crew are not very technically oriented). A last horrible element thrown into the mix is this very reliance on skilled manual workers is costly, and many theaters are working to remove as many people as possible. This increases automation, but not in a good way; it puts more and more things into a "it had better work when the button is pressed because no-one is in a position to monitor it, or competent to repair it."

Perhaps I need to be thinking more in terms of oversight schema; where instead of concentrating on a robust path from sensor to effect, I should be looking at the permissions path, interlock safeties and deadman switches, that permit the effect to operate only when appropriate.

Sorry...all of this drags very aside from Arduino. Right now, I love the Arduino proper because it is easily dual-powered, has a robust enough power supply to run smaller devices, and with the onboard USB chip all I need is a laptop and a cable to tweak the programming.

For more extensive use I'm looking more at either stripped-down Arduino clones, or dropping down all the way to AVR chips -- the AVR-USBs are especially attractive because then I can do HID or (non-compliant) MIDI without any other interface, or the need to load host-side software.

Drat. Been re-visiting my old notes files, and writing up various hypothetical scenarios.

(For instance, what if I wanted a coffin lid squeak every time the on-stage coffin for “Dracula” – one of my current productions – was opened? It is a rolling scenic element, meaning the sensor has to be wireless. And they open the lid to escape back stage so it needs a permissive action link rather than firing every time. And they rattle the lid without opening it so something like a photocell is the best “yes, the lid is really opening this time” sensor.)

The gadget I have I’ve used in a dozen productions so far. But it really looks like the next step is a really, really big leap. What looks like the best form for problems like above is a networked series of wireless sensors, and a full GUI-implemented controller software (probably running on laptop host) that monitors battery status, conditions the sensors, allows on-the-fly adjustment of set points, and allows construction and routing of the final messages.

Something like max/MSP might be better than a hand-rolled package. And the latter is beyond my current programming skills anyhow.

Ah, well. For the short term, as a basically independent project the dedicated Qlab/MSC button is a good project. MIDI-over-USB, powered from USB, low profile, no driver, plug-and-play; it just shows up as a MIDI device and spits “Go,” “Stop” and “Rewind” when the big tactile buttons are pressed.