How to Ring a Prop Phone from QLab

Opening Remarks

There are new plays being written every day, but so many of the plays in our repertoire are older (if not actual old chestnuts.)  Between the aging subscriber base and the desire for familiar pleasures, you can be sure that in most theaters you work at, you will be doing "Charlie's Aunt" at some point.

Which means that although we've moved on in our own lives to men without hats, jackets without vests, carriages without horses, lighting without gas, freezers without ice delivery, in fully half the repertoire older ways and older technology are part of the action.  There are few plays yet in which appear an iPad or a tweet -- but many in which a telephone has to ring.  And I mean ring -- not a ringtone, but the good old electric clapper that was part of our lives for almost eighty years.

Theater sound design is changing as well.  I am tempted to say it might be less realistic, less diagetic, but fuller and more complex.  But that might just be the companies I've tended to work for.  Result being, you are more likely today to play a sound effect off of digital media and through speakers, and less likely to make use of the storehouse of theater tradition with its crash boxes, starter pistols, thunder runs and, yes, phone ringers.

In any case, making a phone ring is an instructive problem.  One word used around the Arduino community is "Physical Computing."  Or, as Tom Igoe puts it, Making Things Talk.  And that is the problem of getting software in the virtual world to do something out here in meatspace.

(How bizarre is it that Chrome's built-in spellcheck flags "diagetic" but not "meatspace?")

And thus, here is how I got an actual period piece of telecommunications to go through its paces once again under software control.

Physical Layer

I got lucky.  I happen to own a 1U rackmount module that puts out Bell standard voltage and ring signal (90 VAC at 20 Hz, super-imposed on a 48v DC offset).  This has been the standard almost since Alexander Graham spilled acid on his trousers (prompting him to call out, famously, "Watson, come here.")  The theater also owns a 90V 30 Hz machine (British standard).

There some cheesy ways to do this.  The craziest and most dangerous is to half-rectify wall voltage.  You then get a sort of pulse DC at approximately 60 volts and 40 Hz.  The next step up in cludge is to use a step-down transformer to bring wall voltage close to 48 volts, then switch it on and off again through relays driven by an oscillator at 20 Hz.  This works better, although it lacks the DC offset.

Better yet is step-up schemes, because these can operate from the safety of batteries or the isolation of a wall-wart power supply.  But this is not the moment to go into those (perhaps later I'll build one of my own from scratch, and document that.)

Since I had the module, all I needed is a relay to switch it.  Since it is an AC signal, I am running it through a relay.  Some reading affords that the ring signal is probably under half a watt, and this puts it within the range of a PC-mount relay.  I was lucky enough to find one at the Rat Shack with a coil voltage of only 5V (12V is a lot more common for relays.)

Since even that coil is a bit too much heavy lifting for an Arduino, a power darlington -- the old standby the TIP-120 -- is running it.  A resistor between Arduino output and darlington just for extra protection.  And, also; when a relay or solenoid is switched off, the collapsing magnetic field produces a transient voltage of inverse polarity to what was applied.  A diode is soldered backwards across the coil of the relay for just this reason; the transient bleeds off through the diode instead of attacking the transistor.

This is quick-and-dirty electronics as well as temporary, so Arduino is fine, with an Arduino proto shield to hang the wires on.  (This is a bare board with Arduino matching headers on it; they have them at SparkFun, Adafruit, and the other usual suspects.  I particularly like the one from Modern Devices myself.)


(The button you see taped to the desk is a back-up, wired in parallel.)

Software Layer

The chain of software starts in QLab, with a combination of MIDI cues, GOTO and RESET cues to set the cadence of the ring.  (New picture, showing some of the MidiPipe window as well as the Processing ap's window.)

To detail a little; the Phone On and Phone Off cues send a MIDI note event.  On is a MIDI "NoteOn" event, and Off is, well, a NoteOff.  These are MIDI cues, which you need to unlock with the MIDI license for QLab (which has gotten quite a bit costlier since the Version 1 pictured here, sorry!)

Both cues are in a group cue so they fire together automatically.  The pre-delay set for the Phone Off cue means it waits for 1.5 seconds before it actually fires.  After an even longer pre-delay, the GOTO cue sends us back to the top of the sound group again.  The actual standard US cadence is 2 seconds on, 4 seconds off.  I picked a faster cadence -- and it works perfectly with the action.

The entire group cue was dropped on the RESET cue.  Which is inside a second group.  This group has a noteOff event in case the loop was in the middle of a ring when the RESET cue was hit, and a sound cue.  So it kills the GOTO, stops all the MIDI cues, fires off a second noteOff to make sure the phone stops ringing, and then plays the answering machine message.

The next step in the software chain is Processing, which receives the MIDI event sent from QLab and sends a serial message to the Arduino:

Above is the window for the Processing ap (compiled as a stand-alone).  As you can see, it gives no options for selecting the correct ports; those identities are hard-coded.  The display text exists only to confirm everything is working correctly.

(There is also MIDIPipe working here because Processing wouldn't recognize QLab as a viable MIDI source).

The key functions here are at the bottom; the NoteOn and NoteOff function are from themidibus library; they are called automatically if the appropriate event shows up at the designated MIDI port.  When each function is called, a single ASCII character is output to the selected serial device (the associated Arduino).

The rest of this is boiler-plate; list the available ports, pick a port, instantiate a MIDI object from the themidibus class.



The last stage to the software chain is the code loaded on the Arduino itself:

Even simpler code here (and a lot of it is leftover cruft from a different project and doesn't actually do anything here).

We're using the hardware serial port and the Arduino serial library.  It simply checks on every program loop if there is a character waiting on the serial port.  If I had saved to a string, I'd need to flush that string on detect, but in this case it just has whatever character is present (usually "null.")

When the right character shows, the relay and a blinkenlight are activated.  Since the outputs toggle, they remain in the state set until the loop is presented with the appropriate serial signal to turn them off again.

I added a button to perform on-board testing and over-ride the Processing end, but never got around to coding it.