Teal Deer

So in the middle of working a morning show and doing overtime at my regular job to try to make up those missed hours, and with a lighting design racing closer and closer...my car breaks down. And it has been raining hard all week.

Yesterday walked to work and back in the rain, worked ten hours in soggy shoes, came back cold and exhausted. Weird. Usually I just grab something from the deli across the street, but I was so tired I actually decided to cook something. And before I could start a curry, I found myself cleaning the kitchen.

I still haven't gotten the benefits package at work, but they are promising a raise with it now. When it happens. I still miss building scenery. Also weird. I'm helping to make a physical product -- heck, I've assembled some of the final product myself -- but it doesn't feel "real" in the way that the (obviously ersatz) theatrical scenery or props do. Maybe it's the theatrical audience that makes it seem more real.

But with all that said, I'd be just as happy not working any shows for a while. I'm finally starting to adapt to work, and yes it is a little boring but not so much as to drive me stir-crazy. And I'd just as soon spend my evenings running out to TechShop or otherwise working on props-related projects. I don't have a huge need right now to get involved in the craziness of Tech Week on top of this full-time work.

(Especially this coming couple weeks; lighting is going to take some long nights, I still have the kid's show in the morning, and I don't want to take a lot off time off work because my boss is on vacation and I'm covering for him!)

So a good curry, ten hours of sleep, dry clothes, and a Saturday morning on which I have nothing explicitly scheduled. I need to go up and look at the roof. I'd love to do more cleaning. The radiator guy may call about my car. And there might be a rehearsal and I'd really like to watch one or two and take notes before things go crazy there.

But right now I'm listening to 20's jazz and finishing a mug of fresh-brewed coffee and thinking about electronics projects. I just threw together a sound board light that I'm using on the current gig, but that -- as well as a couple other ideas that came up during the show -- would be easier if I had some DuckNodes already created and ready to pop in. (For this, I was able to clumsily re-purpose the simple driver board I last used inside a prop radio).

Over and over, I feel I should be able to grab something out of a bag when someone at a show I'm designing asks "How can we make the gunshot sound match what the actor is doing?" or "How can we put a light inside the magic lamp?" But as hard as I try I can't seem to get over a basic conundrum.

I'm fine with making something that is too complex for the task -- a Swiss Army Knife when all you need is a pair of tweezers. I'm even okay with the larger footprint. The power issue is a little messier, as is the question of command direction (aka, does it send a command from the stage, or get a command from the booth?) But the real stumbling block is that the real flexibility is in software.

In software, the same physical circuit board can either run a pre-programmed chase sequence, or can respond to a voice Dalek-eyestalk style (or do it multiband, graphic EQ style) via software DSP. But these possibilities, plus interactive behaviors I haven't yet dreamed up (because the show I need them for hasn't started production meetings yet), exist because of software.

We've basically entered Star Trek (Next Generation) technology here. I can make a black box that is essentially agnostic as to the input(s), power supply, output(s) -- the same box can without any physical alterations take a microphone input or a photocell or a microswitch or a radio link, and output to high-power LEDs or rope lights or solenoids or servo-motors -- but Geordi needs to be in the loop.

I've tinkered with this for a while with the DuckLight. The DuckLight, to recap, is a bank of constant-current drivers backed by a microprocessor. I've already built these so you can select (via a dial) what it does when turn on... a candle-like flicker, an Apple Product pulsing, a back-and-forth flashing. It is quite possible to let the end-user dial up some variety to these pre-programmed behaviors with a bit of tricky programming. Possible, that is, but annoying in that programming-the-VCR way of holding down one button and pressing another to try to get at what you want.

The next step up in flexibility is to create a user environment that runs on a personal computer. This is the most economical solution, but it bumps the per-device cost by at least ten bucks to permit full USB connectivity, and even then probably requires the end-user fiddle with drivers. And then there's a terrifying amount of programming to try to forecast what the end-user might want to do and break it into a simplified presentation of options via a custom GUI.

So, really, it makes the most sense to just go right to programming the device directly. The physical infrastructure is no more costly or complex. In my opinion, the learning curve is no worse, either. And the flexibility is vastly greater. But to a lot of people, being asked to program is an insurmountable barrier. They won't get the thing because they fear they won't be able to do this. (And if they have the confidence to program it, they are already half-way to just building their own physical layer as well!)

So thus I keep stalling on the idea. I can make these things for myself. But I can't figure out how to make ones that would be useful to other people. Not ones that will offer the inherent flexibility to do everything from connect a physical doorbell on stage to a sound effect played from the booth, to putting a pulsing lighting effect inside a stage prop.

More Blow-Back

I've been scribbling ideas for a new prop. But I also learned that one of my theaters is doing "Mockingbird" this season, and are already having questions about how they are going to do the gun.

I've done this once; for "Tis Pity..." the actor had a plastic gun and a keyfob transmitter in his pocket. He'd press the button while miming firing the gun, and the sound played out the sound system. Which is how I ended up cleaning stage blood out of a radio transmitter but anyhow.

The idea I meant to throw together was basically a cut-down Nintendo Power Glove. One flex sensor in a fingerless glove (or a flesh-colored finger cot) leading back to a XBee or similar radio transmitter.

This does have the advantage of simplicity. XBee modules have onboard analog to digital converters, and can stream a steady set of samples from the sensor. On the other side, a simple carrier allows you to bring the serial data stream into software via a USB cable. This is what I did to interpret the accelerometer data when I was messing around with a spell-casting wrist band. Since the parsing is done on the host computer, you can display the real-time data from the sensor, log it, look for patterns, adjust limits on the fly.

The downside is cost and battery life. The XBee pro is $50, and to make the sensor really responsive you have to be transmitting almost constantly.



But I realized yesterday, as I sat in a brush-up rehearsal of someone else's show scribbling away on notes on my laptop, the trigger finger sensor may not work.

The problem is recoil.

There's been a steady effort to simulate recoil in game controllers and laser tag guns. I'd been looking at those options that very day, towards the prop I mentioned above. On stage, it is frequently done that the actor will jerk the gun in their hands to try to simulate the kick of a real round. It isn't that realistic, but it is better than nothing (blanks, of course, have very little kick either).

This is the way in which the sounds don't coordinate. You can't exactly see the actor's trigger finger from forty feet away, but you do notice if they jerk the gun; auditory reaction time is on the order of .2 seconds, plus they do actually have to pull -- in a 1980's study, it was a full .5 seconds before a forefinger could be brought down on a button. Using a vibration motor instead of an alerting sound brought it down to .4 seconds.

Obviously, if it is too disruptive to tear open a rented prop gun and insert a sensor (the reason why I've been designing a sensor that is worn by the actor instead), it is way too much effort to put a recoil device on. Especially since the best commercial recoil devices are just about up to delivering a satisfying "kick" to the user -- they don't jerk the gun enough so anyone would notice it from stage distance!

Which leaves us back with the poor actor having to coordinate jerking the weapon back at the same time they operate a button. And because simulating a firearm recoil requires such a strong muscular effort, it probably precludes doing anything subtle and controlled with the same hand (like operating a button, or even like pulling a trigger). Which means you might as well have a key fob in the pocket.



But I may be overthinking this. The problem is that I shoot. The kinesthetics are clear in my mind; you grip the weapon securely, and you ease down the trigger. After you've taken out the slack, that last bit of squeeze is timed to happen just as you are on a resting breath, and the bobbing sights are properly aligned.

As an actor, though, what could I make work? Jerking seems natural, and controlled. Perhaps an accelerometer is what is called for. Assuming I can discriminate the desired motion. Pressing any kind of button or trigger feels wrong to me...but at the moment I'm trying to work this out with a hot glue gun.

Maybe I should build that prop after all. Or run across the street for one of those NERF guns I've had an eye on for my next repaint...

+++OUT OF CHEESE ERROR, REDO FROM START

Spent yesterday with my youngest niece assembling a 4x4x4 LED cube from Freetronics. That's 64 LEDs to solder. They are RGB LED's, also; four leads each, meaning 512 discrete solder joints to make.

Tough soldering, too. The pads are small, LEDs are temperature-sensitive, and the board had overly generous fluxing. But she really leaned down on it and got good joints and she blew through a good half of the LEDs on her own.

(I had to chip in because we only had a few hours in which to work and I wanted to be able to light it up before we finished for the day).




So I fired up the Arduino IDE to run the terminal monitor program and show her command-line interfacing to the completed cube. At least that IDE was looking somewhat familiar to me, but earlier in the day I was looking at pulling an accelerometer from my DuckNode proof of concept, and ended up first looking through Processing sketches to see if I could see the data coming through the XBee link, then running my old terminal ap to talk to one of the XBee modules directly.

Which, yeah; the "+++" is the escape code for the Hayes Command Set. Which is to say; "+++" alerts the machine that the following serial data are to be treated as instructions to the device itself.

And, no, I didn't remember most of my AT commands. So I was trying to code in a language I'd forgotten, running on an application I barely remembered writing, which is written in a language I'd also gotten a little hazy on.

I'm having this more and more. Especially since a lot of applications don't adhere to underlying GUI standards. It gets really annoying when spacebar drag or control-V does something different in the application de jour than what it does across a dozen other graphics applications. Especially when you are flipping from one to the other.

I'm still trying to get used to The Gimp, which goes out of its way (for legal reasons) to do everything differently than PhotoShop did it. And I'm still far behind on working out Blender. But with the software landscape changing so rapidly, and my own interests also spreading so widely, I'm having to on any ordinary day confront at least two pieces of software with unfamiliar interfaces. And worse -- trying to do something productive on them when time is short and the pressure is on!

I had to quickly set up the Arduino IDE and get it talking to the LEDs we'd just finished soldering before I lost the attention of a sleepy kid. At some point in that same day, I was also diving into Reason to show off a piece of music I'd written for a recent production -- and I haven't had that software open for a month, at least.

Over most of this past week I've had Scrivener, Carrara, Fritzing, The Gimp, and Wineskin Winery open as the projects I've been prioritizing (the Jubal Early gun, and the DuckNode), require I jump back and forth between several of these aps as I plan and develop.

This stuff makes my brain hurt. I need food.


(I'm taking a short break from microphone repairs -- have one of those dratted TA4F connectors open now and you need a clear head and steady hand for those.)

There's a Li-i-ight...

I'm rather tempted to throw together a simpler version of the Duck Light just so I can try it out in actual theatrical situations. And so I can start working out the software infrastructure.  I've run a 2W "Cree" with nothing but ballast resistors and power Darlingtons to PWM it.

I've been reading a whole bunch of spec sheets, and it appears that Texas Instruments has a couple of boost drivers that will take PWM. One thing that is a little unclear is if they will actually PWM through the full range of brightness.

But that's far from the only questions. There's some serious engineering still to go. Thermal issues, noise issues. I don't know, for instance, if you can pack three or four boost converters in a small space, and PWM all of them, and not create electronic, RF, or even acoustic hash.

Oh, and they are of course SMD components. Which is a whole other subject to learn (besides the fact that I actually need to have a PCB made for this; strip board and SMD's do not get along).




I have to keep wondering if I am parameterizing this correctly. Obviously I can't fill the entire wishlist. There will have to be design compromises. But I may be letting myself be constrained by choices I shouldn't be making.

Here's the basic outline;

"A tiny battery-powered LED capable of color selection and animation via direct input or remote control, for use in theatrical props and special lighting effect situations."

This seems to imply the following;


1) 3-5W RGBA. The complexity of the power and thermal management get much, much higher when you get above around 400ma per channel. And the cost of the LEDs also roughly doubles. At this wattage, the LED is as low as $14 at Digikey. It is, however, on the low side of what I think will be effective on stage.

The "A" is a similar trade-off. You don't have to use a four-die LED, but for a lot of theatrical applications having a dedicated amber channel will really improve the effect.


2) Custom PCB. I want it compact, and as cheap as possible, so it doesn't make sense to use Arduino compatibles, shields, adaptor boards and/or breakouts, and all-in-one LED drivers (like the BuckPuck). A PCB brings everything together in the smallest and most economical form-factor.


3) AA batteries. Basically, I'm assuming these are theatrical effects, not static displays. Meaning they are only operated for minutes at a time, the length of an Act at most. Theaters with wireless mics already have an established routine for swapping out AA batteries (rechargeable, or bought in bulk). And their power density is much better than coin cells or 9V "transistor batteries."

Sure, Lithium polymer have even higher density, and smaller sizes (as well as higher voltages), but I think the tradeoff in being able to send it out on stage with known fresh batteries far outweighs the simplicity of onboard recharge.

And that restricts me practically to wanting 3 to 4.5 volts base (and, actually, lower, because of voltage drop over use, and of course rechargeables are lower voltage to begin with).


4) XBee socket. It just seems the simplest way to integrate remote control; the XBee is demonstrated as getting a clean signal at stage distance, and the serial communications are really easy to work with. I've used XBee-and-Processing systems on stage, in actual productions, so I'm willing to put up with the size and cost of the modules.

And using a third-party breakout just multiplies the cost and size. However, I won't rule out having my own add-on board or a breakaway tab.


5) ATtiny or through-hole ATmega with ICSP programming header. The reason here; I just don't have the time right now to learn the USB stack, so as to be able to program via a native USB port.

I also think there's a natural division; assuming I can get this into kit form, most end-users are going to operate through the presets and the Processing ap I mean to write. Those users who want to write custom software into the light, are the kind of users who have an FTDI cable or similar lying around.

I could be totally wrong, though. Which brings up a real question; does it make more sense to do the entire thing as a shield, designed for compatibility with a Micro, Teensy, or Trinket? It is a question of whether adding the cost and footprint of a daughterboard for the CPU is worth having some-one else's well-tested USB bootloaders.



The ultimate trade-off is still; can I make something small enough and cheap enough and easy enough to use? Because you can always wire a Cree straight to a set of batteries with a ballast resistor and a simple switch. All of this added cost and complexity in setting up is just to achieve custom color mixing, the ability to animate, and the ability to add remote control.


Argh. I just discovered buck and boost converters require a minimum voltage difference between supply and output -- 2.5V in several of the ones I was looking at. The forward voltage on RGBs of the single-die kind ranges around 3v. That's pretty inconvenient for wanting a power supply in the 3V range! Maybe my test board should just be tip120's and 2-watt resistors after all...

Duck Duck Goose

I keep finding other things to keep me busy instead of working on the Arduino Controlled Lighting Source (aka pairing a 3W or better RGB LED with an AVR and basic battery management).

And yet again, an application comes along that if I had the gadget, I would use it.

That's been part of the problem. I try to brainstorm what shape the circuit should be to be a flexible general-purpose FX tool for theater. But I have trouble dreaming up the actual applications. Until a show comes along -- like the light-up coat for the WIZ, or an on-stage miner's lamp -- and I realize what I wanted to have had available.

The application that got dropped on me yesterday is to have a light inside a locker that pulses Dalek-style with the voice of the actor. Now, I have one already:

Which works, more-or-less, and will do this show (this has a 741 pre-amp, which is bypassed, a 386 power amp which is pretty much a waste of space in this design, and an ATtiny45 programmed off-line via the Arduino IDE. Under the heat sink is a power Darlington; it takes audio input on one end, and can control 50 feet of LED strip light at 12 volts at the other).

Using this of course requires running power out to the light itself. Or you could run the lights with a battery but the audio would still be on a wire. 

The PLS (to borrow Tomb Raider terminology) is designed from the get-go to be portable, and battery powered. And to have a remote link.

But where this gets interesting is in processing audio. Upon reflection, the neatest way to do this may be to treat audio as just another input stream on the host computer of the controller node.

So the topology works this way; a Processing ap written to take an input of Core Audio, and spit serial commands out to an XBee node. On the remote end (the light-up locket, in this application), the serial data stream through the second XBee node sends real-time adjustments to the desired output, and the AVR runs the PWM serving the light.

(One thing I've been freezing on is sometimes I want a general high-power switch, such as a trio of Power Darlingtons: and other times I want three constant-current drivers matched to a specific compact LED.)

(Or maybe four; a lot of lighting effects look better with a RGBA instead of RGB. Especially anything that is trying to simulate light heavy in the ambers; firelight, candles, oil lamps, etc.)

(Because while I dream of Green Lanterns, two recent applications I might have served with this both required a different form factor. The WIZ coat had light-up lapels, and the stage had almost fifty feet of the same LED strips).

The other thing I'm realizing with this is that rolling custom software is probably going to be necessary in most of the applications that pop up. I can easily see needing to process audio, for instance, but doing a Fast Fourier transform on it so frequency is the driver, not amplitude. I also noticed during The Wiz that having a DMX512 option would be extremely helpful!

Most of which is host-side, but then there's applications like Crystal Ball or Blaster where the data (actor's movements, sensors, controls) are at the end node, and it adds an unnecessary level of complexity to have to send all that sensor data back to a host computer where it gets interpreted.

Oh, yeah, and unless your theater employs a Hollywood Hacker, no-one is going to write raw code on an ad-hoc, application-by-application basis. Which means that even if there's a central coordinator running on a laptop, taking MIDI from the pit or button-presses from a Stage Manager or sensor data from the stage, and sending it out to remote nodes that light up or throw relays and solenoids, there needs to be a complete, robust, and extensible software framework.

Which is as much beyond my current software skills as engineering a proper set of constant-current drivers with PWM is beyond my electronics skills.

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.

Snow Crash

Well, the crazy system I am running "Drowsy" on finally let me down.

It has been a show full of fun.  Opening night the main rag slipped the lower pulley and barely made it in and out, and the work lights were left on, spoiling the opening blackout.  One night the follow spot got locked out of all cues and they had to turn it on manually.  Which was good, because the next night the "robo-light" (some moving light, I don't know the make or model) didn't light, and they had to cover for it with a manual follow-spot.

I'm running all the sound through my laptop.  Well...everything but backstage and conductor's monitor.  Us old-school techs are scared of depending on a computer.  I've seen a BSOD in a booth.  I've had to restart a Mac a couple of times, too.

Here's the set-up; wired microphones along the proscenium line, four wireless belt-packs on actors.  All plugged into a Mackie 1602 mixing board.  Then the group outputs of the Mackie are run into a MOTU firewire interface and into the computer.

In the computer, Reaper takes the different buses (proscenium mics, wireless mics, off-stage chorus mic) and processes them with compression and graphic equalizer.  (Plus there's a little corrective EQ done in the MOTU itself with its on-board DSP.)  Then Reaper exports to the primary firewire outputs, which are plugged directly into the house mains.

The other outputs of the MOTU are being sent to effects speakers.  QLab speaks to those.  And as I mentioned in a previous post, QLab is also generating MIDI events which are translated into a serial signal via a Processing sketch, and sent to an Arduino that switches the practical ringing phone on and off.



Saturday I had no signal on the vocal bus.  Same night we lost the moving light.  And, of course, it was the night I had friends in the audience...!

There's no intermission.  There really isn't a spot in the show where it was safe to reset the systems or otherwise do anything more than the most conservative problem-solving.  So I routed all the mics to the one working bus and worked with that.  Which didn't sound anything as good, but got me through the show.

Part of the problem was, I couldn't send any useful diagnostics to headset, and the average vocal material was too low to tickle the meters.  As it turned out, I still had the chorus mic bus, and that would have helped me zero in on the problem.  But the only times I had a hot enough signal to trace via metering, were times I didn't dare do anything that might kill the signal.

Well, following the show I could.  And it turned out...Reaper was fine.  The computer didn't crash.  Even the MOTU was fine.  The problem was on the group faders on the Mackie.  For some obscure Mackie reason, if the button to assign a group back to the main bus gets some corrosion in it, the signal out of the unique group output goes dead as well.

All it took to restore the sound was pressing the button a couple of times.  Today I sprayed the button, and the show went flawlessly.

And, yes; the contrast between not having the computer properly in the loop, and having the corrective EQ and dialed-in compression I'd set for the vocal mics....well, it was a huge difference in how transparent the reinforcement was.  So I am prepared to say this was a good way to do it.

ET Phone Home

In The Drowsy Chaperone the MAN IN THE CHAIR goes out of his way to explain to the audience, "Yes, records" before he puts one on the phonograph.  Oddly, though, he doesn't mention that he is using a dial telephone, and an answering machine with those little tape cassettes.

I am living in future shock once again.  When I started in theater sound phones were common and easy to find.  Not any more!   

Anyhow.

Today I got the QLab-controlled phone working.  But I haven't decided if I really want to trust that particular Heath Robinson for the run of a show.  The original reason for the contraption was that the Stage Manager was going to be running sound cues, and I didn't want her hammering at the button of a Tele-Q in the middle of a cue sequence.  Thus a system that will start the phone ringing as a loop with one push of the GO button, and stop the loop with a second push (which also cues up the answering machine sound).

I was also hoping to save having to run a wire for the 90 VAC ring signal; going with electronic control would mean I could send data backstage instead, through the existing snake.

But things change in tech.  The Stage Manager is no longer running sound cues, and whilst cleaning up the old wiring I threw a chunk of recycled garbage cable up anyhow.  So I already have a button and I've been using it in rehearsal and, really, it works fine as is.  The only reason to continue with the electronics is to prove I could do it.



Start in QLab.  With the MIDI license, QLab will create and send a MIDI event.  I picked, arbitrarily, note #64, with noteOn for a ring and noteOff for silence.  A GOTO cue (another one of the special cues unlocked with a QLab license) sends the pointer back to the first cue again, and pre-delay on the various cues sets the ring cadence.

(The Bell standard is 2 seconds on, 4 seconds off, but I'm using a faster and more theatrical 1.5/3).

It took a bit of experimenting, but the way to end the loop turned out to be putting them all in a group cue, ticking "go to next cue" in the group cue settings, checking the "continue" box in each of the MIDI cues and the GOTO cue.  Then, I dropped the entire group cue on a RESET cue, which turns off the GOTO and exits the loop.  Which auto-follows (the "continue" check-box ticked) to a second noteOff MIDI cue; this way, no matter where I am in the loop, hitting the "Phone STOP" cue will turn off the bell.

Had things gone according to plan, the Stage Manager would have been using this pair of cues to control a sound effect while I finished wiring the actual phone up.



Anyhow.  QLab does something non-standard in MIDI and it doesn't always show up as a MIDI source to other applications.  I'd had this problem before.  So instead it is patched into the handy freeware MIDIPipe.  This creates a new virtual MIDI source called "MIDIPipe Output 1."



The next application in the string is a clickable (Java virtual machine) application written in Processing.  Using the MIDIBus library, it detects the MIDI note events sent from QLab.  Then it writes a "p" or a "o" to a selected serial port, depending on whether it saw a noteOn or noteOff. 

It is pretty much a garbage ap at the moment.  I hacked it up from the Wiz software, stripping out the XBee signaling and pasting in basic MIDI functionality from a MIDI Bus example program.  It has at present no way to select ports other than re-compiling.  Heck, it doesn't even NAME the ports it is using.



The older generation of Arduinos use an FTDI chip to show up as a virtual serial port over USB.  This is what I'm using here.  There is an Arduino on the other end of a USB cable, and when it sees a "p" or "o" at the serial port it sets the output level of two pins.

One pin holds an LED and is there as a blinkenlight.  The other is running a 5v relay via the venerable TIP120 power darlington.  The only other components are a resistor on the input of the TIP120, and a diode backwards across the coil of the relay (to protect the rest of the circuitry from the field-collape induced surge.)

And, finally, the relay closes the connection to the steady 90 VAC at 20 Hz from a industrial-strength piece of rack mount gear I happen to have lying around.  If I had to generate the entire ring signal from scratch this would all look rather different.  As it is, all I have to do is switch an existing voltage.

And at that point the actual dial phone on the stage rings, just as if it was forty years ago and still in ordinary use.



An annoyance I'd expected but hoped to avoid; QLab breaks the "Reset" cue every time the program is closed and re-opened.  Next performance, all the "Reset"s were still listed and looked normal, but none of them worked.  I had to delete the old ones and write new ones.  For every single phone cue.  And it looks like I have to do this each and every performance.  That is going to get old fast.

Almost Perfect

The WIZ jacket finally failed in performance.

I'd been making a repair about once a weekend.  Each of the ballast resistors came loose once, and several of the solder joints to the flexible LED strip on the collars broke, but until Sunday matinee it had a flawless run.

I am still deeply satisfied, because I am not a little surprised.  It was thrown together so quickly, and I never had the in-depth testing cycle I wanted.  I didn't honestly expect it to make it through Opening Weekend without flaws.  And it failed in a good way; it didn't turn on.  If it had failed to turn off, or if the lights had gone dead along one side, the audience would have realized something was broken.  As it was, the scene was merely a little less magical than we had intended.

I'm not 100% sure of what went wrong, and this is because my procedure was diagnostic, not forensic.  When I looked at the coat, the 9V style battery jack had pulled entirely off the battery pack.  Presumably the dangling length of battery cable had gotten snagged when he was dressing for the scene.  I've taped that now, and tacked up the dangling cable as well.

But when I plugged it back in, the coat still didn't answer the controller.  The picture above was taken by a co-worker after I'd pulled all the equipment boxes out of their pockets in the back of the coat and was probing at them. 

Blinkenlights on the Arduino and the XBee Shield showed they were getting power -- so battery cable, that part of the wiring harness, and the power regulators all checked out.  When I opened up the power switch box (the Altoids tin) I confirmed power at the busses there as well.

I plugged in a USB cable and via the Arduino IDE looked to see if I was getting a serial response out (there are several serial print commands written into the coat's software for debugging purposes.)  Nothing came out.  I reloaded the Arduino software.  Still nothing.

Rebooted the control software on the laptop (a Processing application that talks to the XBee transmitter on a Sparkfun USB breakout).  At that point, the Assoc Light lit up on the coat's XBee module, the coat confirmed reception of controller commands by echoing them back through the Arduino IDE...and the lights lit.

So my best guess is that simultaneously, the Processing ap borked (possibly because someone had jiggled the USB connection and it didn't restore it properly), and the plug pulled off the battery pack in the coat.  But I can't rule out that the software on the Arduino went bad (this does happen) and it needed to be reloaded before it would work again.

Wasn't a waste of my lunch break, though.  I took the opportunity to tack down the bags holding the equipment boxes, and tack down more of the wiring.  I've been tempted to take the whole thing home and re-stitch the equipment bags and add proper velcro closures...but it works, and it made it this far, and we've only got two weekends to go.

Non-Linear Playback; The Evolving Story

Seemingly all the sound effect designs I do these days have some non-linear elements.  But at the same time, the majority of the show is still effect by effect; often called and/or executed by the Stage Manager, and presented in one long list.



"The Wiz" (which is running now) is one of these standards.  My Sound Assistant is on headset, taking each cue from the Stage Manager.  I've built in dips (fade cues and restore cues) to take down the sound effects during songs, and these are also being called as lettered cues by the Stage Manager.

The one exception on this show is also the first time I've had someone other than myself executing an improvised effect.  To wit; the wind effect for the twister is meant to be artificial, to be more like a performance on a synthesizer patch.  Which it is; my Sound Assistant has a tiny Ozone keyboard by him, and he performs the wind effect each night.



This last weekend I opened and closed "Starmites."  Four-performance run.  In that case, once again, the majority of the cues were presented in linear order; they were programmed into QLab, run off a laptop, and the Stage Manager herself was pressing the "Go" button.

I had a second laptop at the FOH mixing position.  There, I had copies of several of the sounds, several background loops, a foley-type effect and an electric guitar patch.

Taking these in order; the tech was abbreviated and the cast sometimes uncertain of their actions.  So there were a couple of sound effects I had duplicated so if the kids jumped a scene, or we'd messed up and forgotten to put in a sound, I could fire it from my keyboard instead.  The nature of these sounds (mostly magical attacks) is such that it wouldn't be a big problem if we accidentally both played the sound at the same time.

Which in fact did happen -- but as always I had thrown master faders for the sound effects on to the top layer of the mixing desk, so it was an easy matter to fade out the duplicate manually.

The background ambiance cues were on my computer because of the harried tech.  Even though I had the sounds built, it was simply too much to add them to the Stage Manager's book during what were already difficult technical moments.  These were low-level looping background effects anyhow so it was fine to just add them in to taste from the keyboard with one hand whilst I mixed the show with the other.

The guitar was there because the MacGuffin of the show, "The Cruelty," is basically an evil electric guitar.  We were hoping the band would do some guitar stuff as the prop was revealed, but that never quite happened...so I did some random fumbling live on a nice crunchy patch with a lot of echo (and a ton of bending).

The foley....first time I remember doing something like this was for "Honk!" where there was a whole bit about a man with squeaky rubber boots.  So I threw boot squeaks on to two keys of my sampler and followed the actor as he walked around.  

This was a similar gag.



So far, however, the only actor-triggered effects I have had were the Duck's "Universal Remote Control" for "Click Clack Moo," and a pistol used in a production of "Tis a Pity..."   The latter used a 424 kHz radio link to trigger a QLab sound cue.  The former was using a quick Processing sketch to interpret an XBee signal and play back a sound.

Oh, and an intercom buzzer for "Moonlight and Magnolias."  That was a strange compound cue; the practical switch on the prop intercom was detected by an Arduino that spit a MIDI message all the way upstairs to where Sound Cue was running on a PC.  Usually, the secretary was on "the other end" which was an actress backstage on a microphone that was fed into the same speaker.  But at one point she "connects" several other callers, which were pre-recorded voice-over sessions -- and these were played back over Sound Cue as Stage Manager "called" cues.

I've now worked on that signal chain so I have now a custom Processing ap that reacts to various inputs from battery-powered XBee radios and spits out a MIDI signal that can be picked up by QLab or by a sampler or Max patch.  I've used it with a Staples "Easy" Button modified for XBee wireless link, and with a basic accelerometer setup on a wrist band...but neither has yet been in a show.

Next on my programming chores is to add the ability to select a sound file for playback from within the Processing ap, to allow skipping the MIDI step entirely for simple shows.  But at the moment, that is my state-of-the-art in non-linear sound.

Wiz Report II

So.  My first wearable.  We've learned a few things over opening weekend:

-- You can punch a 2.5 gighertz signal through metallic brocade, an actor, and a hundred feet of air, but it takes power.

-- You can dance and sing with an 8-pack of AA batteries on your body.

-- An Arduino, an XBee radio, and a meter of PWM'd LED strip doesn't create enough noise in a good wireless microphone to matter.

-- 60-LED-per-meter RGB is actually overkill.  We were afraid the costume wouldn't be bright enough to be visible over stage lights.  It is so bright I'm thinking of turning it down! 

-- Client-side works, and does permit more elaborate/faster animations, but server-side is more flexible.

-- Digital would be better.  Soldering all those leads for analog RGB was no fun.  Also, the leads on the RGB strips keep coming loose.  Digital is only a few bucks more -- and allows even more elaborate animations, too!

So that's the thing.  This is actually turned down a bit.  The look is simple; LED strips stitched along the edges of the lapels, and 3W LEDs under the shoulder things.

The electronics are in pockets stitched to a vest, which hangs loosely inside the jacket so as not to disturb the hang of the jacket.

Here's the signal chain;

A Processing ap allows the operator to click on one of several programmed "looks" (most of them are animations; pulses, flickering, color swirls).

Processing spits out a serial word to a SparkFun USB adapter holding a Series 1 XBee Pro.

The signal is picked up by a matching XBee on a Seeed Studio mini-shield, and sends the serial word on to an Arduino via Soft Serial. 

The Arduino, running in a form of RTOS, routes through one of several programs to output the three PWM signals.  Which are basically lifted from the "Blink" code I wrote a while back.

These are sent to a second box containing the switches and drivers; Tip120 power darlington transistors switch the LED strip, and "MR16" type constant-current drivers switch the 3W "Cree" LEDs.

Then the wires all come out the back of the neck, under the collar, and are routed to each lapel and to the shoulders.

On each shoulder, a "Cree" with an improvised heat-sink of aluminium channel pushes light into a half-dozen random lengths of plastic light pipe (bought at SparkFun, and probably the most expensive part of the costume electronics).

The final effect is QUITE bright.  (The picture to the left is under work lights.  I had to stop the camera down considerably.)

We only use it for "So You Wanted To Meet the Wizard."  At the top of the song, it glows green (shifting subtly between yellow-green and blue-green).  For the soaring "B" section, it goes to a shimmery blue.  And at the end of the scene, ("I have spoken!") it goes to a rapid mostly-red flicker/flash.

During the dialog scene we're running it at an extremely low setting (analogWrite(green, 8)) just to give the costume that hint of sparkle.

And of course we black it out at the end of the scene.



Next time I do something like this, I'll use either an Arduino mini or similar, or a proper wearable like the new Flora.  Although XBee support is a little minimal on those options.  I'll also go with either AAA power pack, DC-DC boost converters and a smaller set of batteries, or perhaps liPo.

I'll also probably skip the driver board.  You do need a switch for analog strips or the Cree, but for many costume applications Flora pixels or digitally-controlled LED strips are plenty.  And those have internal drivers; all you have to do is supply enough amps from your battery pack.

But for this show...since I'm taking the CPU back after the show, the total cost of the electronics was about a hundred bucks.

This show was very much thrown together during Tech.  And I haven't had a chance to go back and tidy up yet.  Here's the Vox Box, as used in the show; propped up on top of the amp cabinet by the snake, plugged into a Behringer micro-mixer to boost the audio signal it is getting.

Since the lead's microphone is fed into a dedicated mix bus for this effect, I can adjust the response somewhat from the mixing board during the show.  The one thing I haven't been able to do is set the lower trim; that would involve running backstage to turn a trim pot inside that Altoids can there, during the song.

And a good thing I put the heatsink on.  I measured a bit over six meters of platform, and purchased two five-meter rolls and a power supply designed to drive one roll worth.  Then they decided they wanted to extend the LED strip along the ramps leading up to the platform in question.  That makes it the full ten meters, and is well above what a TO-220 package transistor wants to dissipate without a heatsink. 

Soon, though, I will change over to Power Mosfets, which have a smaller voltage drop and hence run cooler (as well as producing brighter effects).

Sometimes Hacking IS Better

Embarrassing.

It took all of ten minutes to run a wire from my computer's headphone jack to an Arduino, hook up the strand of LEDs I have wrapped around the monitor (via a TIP120), and throw a bit of software together to blink the one in reaction to the other.

But I wanted something neater.  I wanted it bulletproof.  At the moment, I've managed to make something full of holes.  Instead of being bombproof, it looks like a bomb.  From a cheap movie.



A day or two to get it all working on breadboard; LM368 amplifier, LM741 balanced input stage, two trim pots for gain and DC offset, and another of those ubiquitous 7805 voltage regulators.

Of course when time came to put it in a box I tried to be fancy.  And thus blew a full day on just that.  Adafruit Altoids-sized perma-proto board.  Not quite enough room for jacks so I stuck Euro-strips on the outside of the mint tin.

First problem; the TO-220 style heat sink was too big to close the lid on.  I may hit five amps on this (I suspect it will be more like two amps in practice but I'm trying to play safe, right?)  So the box is without a lid.  And the components got even more cramped.

Second problem; I bricked both my ATtiny45's, and there isn't a simple way to port Arduino code (or use the Arduino IDE) on my one remaining AVR; a venerable ATtiny13.

I have some ATtiny85's on order (more 8 pin dips that will run at 8 MHz on internal oscillator).  In the meantime I had to get the rest of the circuit running, so I strung wires to an Arduino that very much doesn't fit in the box.

(This may still be a problem; the code will need adapting for even the ATtiny85's.  I might need to program in C anyhow.  But I lost my old AVR toolkit in a computer crash, and the new one seems to make it much more roundabout -- in the interest of "better and more efficient," of course! -- to access the registers.  Plus, I never did figure out how to work the ADC, which turns out to be rather more complex than doing PWM and other timer interrupts.)

Oh, and although it worked fine on the breadboard, the balanced input stage refused to work in the box.  And I rebuilt a duplicate on the breadboard and patched it in and it still doesn't work.  So I gave up and jumpered over it.

Which means at this stage, I could have just popped a shield on an Arduino and been done.  Not like I'm really going to need this specific circuit again, right?



It also struck me, as I was setting trim pots and juggling op-amps, that I could have just done the whole thing analog at this point.  I did it in digital because that gave me the ability to do signal processing in code; control the dwell time and so forth.  Except I'm learning that the audio signal varies so widely, software adjustment isn't sufficient.  I needed to have analog real-time adjustments (aka trim pots -- even if one of them is fed into an ADC port in order to set an offset number).

So no pictures for this entry.  I'm too embarrassed by the thing.  Pics after I've patched it up into something nicer.



So my other show-off project before tomorrow's meeting is to fake up the first DuckNode.  One problem; the only analog accelerometer I have is on my POV stick, and I don't want to take that apart just yet.  So I may have to wire up the I2C accelerometer, adapt the code to a friendly I2C library...and THEN wire the analog one on to an XBee.

The big question is whether I can remember what I'm doing fast enough to adapt my work-in-progress Processing framework to detect the remote accelerometer.  I could use another weekend to work on this!

Robot-Robot

TENTH DOCTOR:  "Does it have to do that?"


So we're closing in on the first robot.  I had the guts of my old "Square Candies That Look 'Round" -- Arduino, micro servo, and a Sharp IR distance sensor -- and my intention was to work around the shape and look of the components and dress them up in some cool way.

The niece had different ideas.  She really wanted the robot to have a big, box-shaped head.  So after looking over the materials we had, and keeping in mind how lightweight that servo was, I had her put together a box from three-eights pieces of white expanded foam.  My usual method with this material is smooth it with wallboard compound and/or gesso, paint it up with thinned white glue, and spray paint.

But we've been doing robot in short sessions, and we just couldn't wait long enough for multiple coats to dry.  We gambled, did one light coat of glue, and I hit it with the spray.  Which bubbled up quite a bit but the thing survived and, actually, the effect is kind of cool.

Unfortunately even though it is light, it is large enough so torque is an issue.  So I needed to swap out the cardboard box with something heavier.  And that servo is running rough, so I'm also swapping out for a standard-size.  Which, I'm just this second thinking, might mean I need to go to a board with a separate power supply.

(If I had any money I'd pick up a metal-gear micro from Adafruit instead.  But I have a couple standards lying around, so that's what I'll use.  A bigger issue is the lack of resolution and the rather noisy output of the Sharp.  We're really asking it to do more than it can do here.)

Anyhow.  While I was tinkering with finding a nice box to put everything in, and trying to decide if I was going to leave a full Arduino or port the code to a cheaper stand-alone, I realized there was a simple way of setting it up so the niece could get her feet wet on programming.

Write the basic code on to an Arduino.  But add a serial read command that will put new values into key variables (like dwell time, seek speed, sensitivity, etc.)  And then write a Processing ap on the front end that spits changed values down the USB cable.

My programming skill isn't quite up to having the Processing sketch re-write the flash, so the idea would be to toy with the values, then go back into the Arduino IDE and hard-code them into the working software from there.  Keeping the software on the micro means the robot remains stand-alone, which I think is good.

Unfortunately, as seems always the way, I didn't think of this until after my free month was almost over, and I'm not sure when I'm going to fit in the time to do this.

Wrestling with Mountain Lions: Don't Fear the Reaper

Yes, I got gifted a fresh new Mac.  It's been an amusing experience.  Throughout most of my computer life I keep getting told by vendors and tech support, "The problem is your machine is too old."  Now, I keep getting told, "Your machine is too new!"

More rant and so forth below the fold:

Objective....Not Attained

I'm taking a break from Objective-C.  The "Hello World" tutorial I was following doesn't work.  Odd.  It is off the Apple site and should be compatible with the latest version of Xcode and Cocoa.  The tutorial included the final complete code and I copied that over to make an exact image -- and it still didn't work.

In the process of trying to figure out why, I learned a lot about working in Xcode, and about the language.  I think I grasp the concepts and syntax of Objective-C now, and am fairly confident in being able to write working code in it.  But the stumbling block is working within the Cocoa framework and in the Xcode development environment.

So I'm ducking back to Processing to move my DuckNode project forward.  Realized that I can model accelerometer data as a point in 3d space -- but it will require I re-learn some of my trig.  If I can plot a combined vector and a single acceleration value, I can construct "target" values as a 3d planar surface.  So the code would ask whether the measured acceleration is of sufficient magnitude to cross the plane, is of the correct vector to intersect the plane, and remains within or above threshold values for a preset interval.  This should be sufficient to discriminate a small number of simple motions.

The next software step, though (work incrementally, remember!) is to expand my current Quacker software to retrieve and display a real-time analog value from a DuckNode.

(Sure, I'm dreaming of more.  I want a piece of software that can display real-time the pin reads off the remote XBee, as well as any serial messages sent, AND pop up a standard AT mode terminal for on-the-fly reprogramming.  But that's all for development.  For the Quacker package, I want it to be third-party friendly, allow patching of multiple XBee receives to both MIDI events and direct software sound playback.)

(I'm still toying with LCARS, of course.  Even though that is a potential huge waste of time -- the interface doesn't need to be pretty, it only needs to work.  The LCARS methods are actually a pretty good match for Processing -- Processing loves doing color-changing blocks and lines of text -- but it isn't necessarily a great interface for connecting a remote sensor to options in a sound or lighting cue playback environment.)

I've also re-thought part of the DuckNode itself.  LiPo might still be necessary for power density -- I need to calculate the drain of not just active constant radio activity (the XBees are designed for low power use, but they achieve that by lowering data rates.  Unless I add an interactive layer for on-the-fly reprogramming of the XBee nodes, I'm stuck with having to run three + analog channels at a high data rate continuously for as long as the node is active.)  Oh, and the accelerometer is also a surprisingly high power drain.

In any case, although "permanently installed" LiPo and a charging jack makes sense for much remote sensing, for theater use it makes much more sense to design around removable batteries.  You don't want to be dependent on the LiPo charging cycle to have a safe margin going into the second show of a two-show day, or the tenth hour of a twelve-hour tech day.  You want to be able to put in fresh, trusted batteries at the top of the show.  And, for that matter, monitor them remotely.  In any case, what with wireless microphones, theaters have an existing infrastructure of AA batteries, often rechargables, and the ability to throw in a fresh pack if there is any doubt at all about the battery status of a show-critical bit of technology.

Mostly, though, I've been working a tough load-in at my local facility.  I'm sore and covered in splinters, and I haven't had the time or energy to do much more than glance at my programming books or scribble a few drawings of interface needs on a scrap of graph paper.

Objection!

It totally makes sense.  The moment I figured out how to create and use a full-functioned class (in Java), I switched to a completely different language with different syntax and different paradigms.  Objective-C, which uses messaging instead of methods, meaning late binding and dynamic typing and all that.

Plus, you know, Processing is a stripped-down version of Java and constructs code that runs on the Java Virtual Machine.  I'm learning Objective-C within the framework of Cocoa and the Apple environment.  Which means I'm exposed to a lot more of the code behind the window than I am writing a Processing PApplet.

And I have yet to get to "Hello World."  Oh, sure; I can create a program that compiles, that has a window and buttons, and the buttons and other elements interact with each other.  But I haven't quite grasped the methods to pass messages to a custom class -- even as much as I've managed to both create a class and instance it in ways that didn't throw up a compiler error.

I'm working through a tutorial right now.  One of my habits is when I'm using example code, whether it is a sample or a full tutorial, is that I will re-name every variable.  This makes it a lot easier to learn which are actual variable (or otherwise user-assigned) names, and which are inviolate software functions.  I also change around other things, for the same reason.

I have to say, though, XCode is a big step up in programming environment.  The Processing and Arduino "sketchbooks" will color code core functions, and highlight matching brackets.  XCode goes quite a bit further with throwing up contextual menu suggestions and auto-fill boxes.  And there is a lot of drag-and-drop functionality, especially around interface design; you literally control-drag an interface item in order to insert the proper messaging code into your text.

I'm still going to be very happy when I finally make a button that can do something.  Happy enough that I may take a break from programming!

LCARS to Z-CARS

I'm not really going to do an LCARS - type GUI for my new XBee software.  Well, probably not!  In fact, especially since I learned you can put a Cocoa wrapper around a Java program, in a way that makes it possible to even do with Processing (or you could just grow up a little and learn to use standard Java)....

Oh, yes.  I downloaded the latest XCode/developer environment from Apple.  I think the last time I messed with I got to "Hello World" but gave up on actually linking to useful libraries.  Maybe this time I'll get further.

In any case, I spent time today learning how to make LCARS shapes in Processing.  Which wasn't as frivolous an exercise as it seems.  First off was finding out about the LINE and BEZIER classes.  And, unfortunately, although lines and lines with rounded ends are a natural for Processing, the LCARS "Sweep" -- a curve that goes through 90 degrees and from thick to thin -- can't be done with those simple tools.

I graphed out an LCARS sweep and plotted it in vertex by vertex; that worked, but besides being non-scalable annoyed me as a long-way-round way of doing it.  More careful investigation showed the LCARS sweep is basically two filled circles; one positive, one negative.

Ah, but the trick is to write this stack of shapes once, and reference it as needed within the program.  This also makes it easier to dynamically change the display!  So the next thing to learn was PShapes; a class that wraps various sorts of geometry to allow it to be manipulated more easily within the Processing window.

Except PShapes didn't seem to give me the instancing I wanted to selectively modify the shapes I called up from the template.  Either that or I wasn't understanding how to properly use it.  The answer was obvious -- it just took me most of the evening, a full mug of coffee and a lot of Bach to get through it.

Object-oriented programming.  I had to actually sit down and make my first full-fledged class.  Not a function I referenced from elsewhere, but a class that could be instanced to objects with methods that could be called on a per-object basis.

And that's done and I feel a little more like a proper beginning porgammer///progerammer//pregoram/////guy who writes code.  Now I just have to refine my understanding of inheritance................

Oh; this has nothing to do with the British television series Z-Cars.  Which happened to include in the original cast a young BRIAN BLESSED.

Pity they never had a uniformed PC on that show named Gordon.  Who would be, you know, ALIIIVE!

Back to Processing

I'm moving away from hardware MIDI.

9/10 of the time, the MIDI signals generated by my various gadgets are going into a laptop anyhow.  And as I gain confidence in programming, I think it is easier to write client-side software than to try to do everything on the embedded processor of a black box.

This seems like it is going to be the form of my DuckNodes.  On the Node end, LiPo battery and charge circuit, monitor/feedback LEDs, XBee.  On the master end, Xbee node with FTDI adaptor plugged into a USB port -- and the rest is software.

Sure, I could dress up the receiver with some indicator blinkenlights.  I'm also tempted to make it in the form of a Diesel-Punk USB stick.  The first show I did using software at the receiver end, I stuck the receiver XBee inside a rubber ducky -- a yellow plastic bathtub duck -- to protect it.

(That's the actual hardware in the picture there; one Xbee inside the television remote, one inside the duck, with the latter connected by USB cable to the Processing sketch visible on the desktop.)

This is a bad time for me to be buying parts.  So this will have to do to construct the prototype DuckNode; a Modern Devices accelerometer, XBee (not XBee Pro), and AAA batteries.  I need to read up on the chip, though, to find out the voltage tolerance and so forth.  But for the nonce I'm working on the software layer, and for that my XBee-equipped Easy Button is sufficient.

Tools

I'm between shows.  No design deadlines, and no props with deadlines either, now that the Maverick is shipped.  So this might be a good time to build some tools.

I've been having great fun with my wireless EasyButton.  Used it to run the lights on one (simple) show.  Used it a couple of times to check sound cues as I walked the house.  Has only been in one show so far -- or, rather, the guts were, transplanted into a television remote and used by the actor/narrator to "control" the action of the play.  (For that show, the XBee triggered a sound effect in a small Processing ap running on a laptop, which plugged into the sound board).

I've had even more fun with my simple MIDI button (this spits out MIDI over the standard 5-pin DIN connector when a switch contact is closed).  It has been in an orchestra pit twice to allow the percussionist to trigger a sound effect.  Another time it was wired into an intercom box to play a buzzer sound.  The flexibility of this is that the trigger is just a button or sensor; the resulting command is interpreted, usually by QLab, meaning we have total control over what kind of sound, where it is placed, etc.


I've been trying to dream up a new device along these same lines, that is a plug-and-play solution for any number of sound/lighting/effects coordination problems.  Something I could have in my bag, that would hook up quickly with minimum wiring to a variety of inputs/sensors; something we can use to explore the kind of dynamic cue'ing new technologies have made possible.

Duck!

My third "Duck" show in a row.  So I brought in my Wireless Easy Button, and they wanted it in the show.  It was fairly easy to cram the XBee into the prop remote (soldering to the board to pick up switch traces was less easy, and the 1-watt Luxeon I put in the front is not nearly as bright as a hoped -- that's the flaw in running it on barely more volts than the voltage drop!)

However.  Instead of using one of my computers, they are using the Stage Manager's computer for sound cue playback.  And that means they are using the free version of QLab -- without the money to pay for the MIDI license.

Fortunately, although the java classes for MIDI are basically screwed on Mac OS and will be for the foreseeable future (heck...it isn't as if java itself has a future on the Mac, with all the effort Apple has been making to have everyone dump cross-platform development platforms and write exclusively on Cocoa)...anyhow, although MIDI is a pain, basic sound file playback isn't bad.  So over the Fourth of July, I sat home and wrote and compiled a stand-alone, double-clickable ap that looks for a serial-over-USB, and when it detects activity at the serial port it plays the sound sample out the default Core Audio device.

It took me a chunk of today to figure out the other trick; when transporting it to a different OS/platform, bring the entire sketchbook folder and open Processing and re-compile from inside that folder.  Between Processing and the Mac OS, I was getting a lot of cryptic error messages instead of a simple "library not found" or "wrong library" and this solved the issue because saving out the entire project this way compiles a copy of ALL of the libraries in your #includes.

And here it is on my not-quite-as-ancient G5:

 

The rubber duck is providing a housing for a XBee Explorer USB, which links the receiving XBee node to the laptop's USB port.  The app window is displaying the selected port and flashes green when the XBee receives a signal.  The hacked remote is under the duck.

The app is total cludge code, of course.  Among other things, I'm not even trying to parse the serial message from the XBee (my mistake on a previous implementation).  Instead I'm simply detecting if ANY serial message is present, and then as soon as I've confirmed that, I wipe the serial buffer! 

(Should have thought of that trick long ago.)



And that's all I have time for.  I have some six minutes of music to compose before the weekend, and I need to learn how to run my new shareware software synthesizer to do it!