The Internet of (Theater) Things

I was at Maker Faire this weekend, and like so many other parts of the inter-tubes it was all IOT, IOT, IOT. And I'm wondering if it is time to rethink the usual objection to using Wifi in a performance context.

The old assumptions were that wifi wasn't reliable enough for performance. But then, we used to assume computers weren't reliable enough. I have seen the pleasant glow of the Blue Screen of Death from a sound booth or two, but I ran into many, many more people over the years who insisted on using tape, cassettes, or (eventually) CD's for effects playback because they didn't trust that a computer wouldn't break on them.

Well, I think most people have moved past that. Computers have become the default for sound playback as well as video playback. Crashes still occur but they tend to get ironed out in Tech; the show-stopper failures I have personally observed have been due to the batteries running dry on a production laptop.

I've seen a slow movement towards acceptance of iPad links to sound boards. I remember when the Yamaha board was iffy at best, but now that Wifi link is considered reliable enough for use in the time-critical environment of Tech and Sound Check on a professional-level show.

(On the other side of the technology-adoption bell curve, I've personally run numerous productions with laptop and software tools due to not having the budget for rack-mount equipment. Sub-mixed drums for one musical on the laptop, and that worked well enough that on a later production I few all of the sound reinforcement through it, using freeware plug-ins within Reaper to achieve a graphic equalizer for the house speakers. My last show, I was running sound effects, projections, and even running lights from the one laptop. And I've seen a lot of this sort of exercise in similar improvised micro-budget shows.)

After all, some of the oldest documented theater technology was borrowed and adopted methods from Elizabethan-era sailors; rope rigging, counterweights, whistle codes. It's a natural path from there to modern techs using cell phones to communicate to back stage (instead of trying to come up with the money for the old-school hardwired headset systems). And a lot of people are using DAWs for sound manipulation or MIDI hosts for live keyboards, or (again on the other side of the technological bell curve) personal music players or similar software like iTunes for backing track and effects playback.

In fact, at some levels of theater it is considered ordinary and natural to plug an MP3 player into the sound board and hit one of those little fiddly buttons at the exact instant called for in the script. (Putting the sounds on the hard disk of a computer with sound playback software that was specifically written for performance use is the more reliable alternative now!)



Which brings us to a segue. Effects -- or more broadly, all the possibilities of both the established ideas of theatrical lighting properties and scenery, and the less widely accepted ideas of interactive technology -- are not exactly called for in the script. One even suspects that in the golden age of musicals and old chestnut standards, the Annie and the You Can't Take it With You, the writer brought the same awareness of what could be practically done with multiple settings in scenery and quick-changes in costumes to what could be achieved in the way of on-stage telephone calls and so forth.

Which is to say, most shows don't require really clever technology to get a sound or lighting effect to happen in the right spot. Between the way the script makes the timing of the effect non-critical, and the way the presentational aspect of the box set with the missing fourth wall et al makes playing a telephone sound out of a speaker appropriate and sufficient (or at least sufficiently appropriate), there isn't a need for something more elaborate.

At least, not there. When you get to more modern works, and better yet, to those experimental works that straddle worlds of dance, improvisation, performance art, et al, there are plenty of spaces to explore more complex interactions than "play back a sound effect at a specific moment in the dialogue."

Of course, these also tend to get worked out in development. Sometimes I have had a performer or a puppeteer or a musician or whatever come up to me and ask, "I'd like to have this happen when I do this; is it possible?" But mostly, a choreographer or a props person or someone sees something interesting that's already out there in the world, and the performance is designed around how that existing thing functions; designed to accommodate the existing advantages and the existing flaws.

(Specific case in point; in a production of Wizard of Oz we used light-up globes extensively. Each time these were brought out, there was specific choreography to allow each performer to turn their back to the audience and page through all the available colors in these off-the-shelf devices until they got to the desired effect for that moment in the show.)

So it seems to me that the process of using the kind of effect modern electronics makes possible starts from the Designer. Instead of problem-solving something that the rest of the design team would like to happen, you become the one to suggest an effect. Which means you are effectively working out of what already exists or is known to be possible, rather than working from something that wants to happen on stage and developing a solution to it.



For that reason among others, I'm not that interested in the experimental end -- in the kind of process that puts accelerometer-controlled LED strings on a dancer, or whatever. Because as I pointed out above, this is more a process of adoption than design. You more or less start with available consumer products, and you develop a way to use them over rehearsal.

My interest from pretty much when I started using electronics in theater (where the height of my technological output was sticking leaf switches around a motor-driven cam to create a hardware string light chaser), is to, well, I'd call it "sweetening."

Here's a conceptual framework from another industry. A movie is more-or-less filmed MOS. In the older days this was a technical necessity, these days it is an artistic choice. Dialog may be taken from the shoot, but the totality of the sound environment in the finished product is a created thing. This is for focus and nuance; the noise is stripped away, and the only sounds still there are those that tell the story -- and they are pushed, too, for artistic nuance and emotional effect.

And this process has already begun in theater. We can't pan, zoom, or cut; we don't have that control over what the play-goer watches. But we do control lighting and we build and even paint scenery to place the eyes and the attention where we want it and to make essential story-telling and emotional points.

And artificial sound has entered. Even in smaller spaces, even in opera, subtle reinforcement and other acoustic shaping is already taking place. In larger houses and in the musical dialog is already passed through processing to make it larger than life in the same way Hollywood takes the best the boom mics and hidden lapel mics can carry back from the live stage, marries those with ADR done in the studio, and presents the final honed and processed mix to the audience.

At the very simplest level, I think we can now have the sound issue naturally from an on-stage walkie-talkie or phonograph or bugle (or appear to), and we can have the light from a television or cell phone (or the lights of other items of technology) doing what seems natural for them to do. The history of technical theater is full of examples of sticking colored lights in empty TV cabinets and sticking speakers under chairs and otherwise producing these illusions. Well, we can do them better now -- even if that means just pushing actual video out through a length of VGA.

But at the more complex level, I think we can have a gunshot sound "right." I think we can have a sword fight with the exiting (and thoroughly fake) sword sounds of a movie. And more subtly, I think we can treat voices and footsteps so the actors sound like they are walking a marble hall instead of wooden platforming.




But many of these require wireless control. Props move. Actors move even more. Cheap wireless is one of the necessary parts to make it possible to bring this sort of realized environment, this sort of naturalistic (or hyper-naturalistic) stage environment. And it may be that Wifi and the IOT has reached a point of maturity where it can be trusted in a production context. And not just on experimental theater pieces with fourteen people in the audience, but in staid professional theaters where your equipment breakdown is seen not by mostly your own circle of friends, but by hundreds of people paying thirty-five bucks a seat.

Purchasing Wireless?

I've been telling people to wait if they can until the dust settles. Well, the dust is pretty much settled. The FCC will be selling off the 600 band; even though the impact may not drift down to us until as late as 2018.

And the digital systems are starting to appear from name manufacturers, and we're almost over the hump of high prices and teething problems of new technologies. Within a few more years I expect digital will drop down in price to similar to what analog systems had been (they are cheaper to make, but the manufacturer can -- for at least the next few decades -- charge more for them because of the enhanced options.)

For the longest time I've been praising the Sennheiser packs. They are built like bricks (metal construction), you can cram 16 units into a frequency band, and they are fairly immune to anything but, well, Shure mics operated in their vicinity (not even on similar frequencies -- mid-range Shures seem to overmodulate and take a larger footprint than you would think).

The worst weakness of the Senny's is the connector to the element, but this is a weak point in all mics -- for me it is a toss-up between the locking mini of the Sennys and the TA4 of the Shures. One caveat; you need sound techs who pay attention and will screw the Senny's back down every now and then. If they do, the screw-on will outperform the TA4. If they don't -- the TA4 wins by default. Both can be aided greatly by added strain relief, done variously with tape and moleskin.

If you simply must go analog, the G3 series is still a no-brainer at the mid-range. If you have the bucks, then Shure UHF or one of the really high-end systems. If you are looking at 500-800 a channel, then the G3 at 600 bucks a channel outperforms the SLX and is (according to a rough weighting of the commentary threads at Control Booth) a bit ahead of the ULX.

For my mind, the Senny wins hand down for stage musicals; not because the ULX has a plastic case, but because it runs on (shudder) 9v. Those have less juice and cost more than AA, and are less common in rechargeables.

(As an aside, there's a chorus of people who crow constantly that rechargeables can never be used for stage musicals. Their reasons are three; that they can't be sure the battery got back in the charger every night, that there's no spare available if you do forget, and that the "gas gauge" gives a misleading reading. All of these are trivially wrong. For the last -- flip the internal switch to rechargeable and the meter will be accurate. For the other two...the critics are imagining a situation in which each mic has its own pair of batteries and there are exactly as many as there are mics. Yes; if you did this it would be a recipe for problems. So you don't. You treat the batteries in bulk and you have double the number, plus a margin. During a matinee, the evening's batteries are already in the charger, and between shows you swap them out.)

(And beside...if your crew is so lame they might forget the batteries, then why are you trusting them to check elements, mute switches, condoms, and otherwise make sure the mics are ready to go? This doesn't speak, to me, of problems with rechargeables. It speaks to a poor approach to prepping mics that is going to give you endless problems with broken elements and other technical issues. Popping in fresh batteries is mandatory no matter what you use, and it is only one of the checks each and every mic must see each and every performance).

Anyhow, the paradigm has changed. My recommendation if you must purchase microphones now is Shure ULX-D. These are 1.5 to 2x what you'd pay per channel for G3s, but they will get you 30 channels to a frequency band and will see you through the coming FCC sell-out.

Plus ethernet access is becoming more and more an essential tool. The G3 series 300 added this, and the 500s make it better, and the UHFs have it in spades. And of course the ULX-D; making full use of the digital channels comes with networked coordination and control.

I'll probably change my mind when I've had a chance to look over a Sennheiser digital, but right now the ULX looks to break the "if it has an X in the name, don't purchase it" rule for Shure mics.

Look Ma, no wires.

I'm having to put together a proposal fast for twelve-plus channels of wireless lavalier mics.

The options haven't gotten better in the way I had hoped, not yet. Only one company so far seems to have brought a digital system into the middle price range, and it is a gigahertz system. I'm not interested. My XBee work has informed me far too well of the difficulties in punching through a reliable signal at 2.4 gHz.

The way things seem to be settling out now, is the price ranges correspond to a set of assumptions from the manufacturers. At the low end, they are generally fixed-frequency systems. Through both low and middle, the manufacturers seem to assume their biggest problem is the users are idiots; so all the effort is towards choosing compatible bands for you. With the result being you really can't use more than one system in the same space at the same time, not reliably. You must purchase a system pre-built with two lavs or eight hand-helds or whatever other package deal they have.

In the high middle of the price range are, finally, systems that are properly programmable, as well as being in wireless bands that are going to remain open for at least part of the next decade, full diversity, standard batteries, etc. So this range starts at maybe $500 a channel and progresses up to the low $1,000 range.

You have to jump up to the low end of the high-end gear, and very much break the $1K per channel of wireless cost group, before you get any of the recent work in adapting to the FCC's latest moves. And these aren't digital. They are other clever ways to shrink the bandwidth and deliver more effective channels in the limited frequency ranges still available.

And some of them are very clever. Top-line Shures can get you fifty microphones jammed into the bands available, and still let you run IEMs for the pit and wireless headsets on your backstage crew.

Thing about Shure is, once you leave their flagship gear -- any time you find an "X" as part of the model name, or the dreaded "PG," -- their quality takes a huge drop-off. Many working audio techs don't know this because they have only worked with Shure; they haven't had the experience of comparing the Shure SLX with similarly-priced units from other manufacturers. To them, the SLX behaves just like they expect; like a Shure you didn't spend quite enough money on.

I'm still looking at Audio-Technica, and even Electro-Voice, but even outside of being in frequency bands the FCC already has in their gunsights, and other issues, they just don't offer on paper anything remarkably better than the Sennheisers. And I know the sennies very well, and can speak to both their peccadilloes and their general reliability.

So I'm probably going to have to recommend purchasing something pretty similar to what I was already in position to rent to them. Sigh.

Flash! Aaaaah....!

Between shifts over the run of Nutcracker I've been getting a lot of work done on my RGB light. Finally tracked down a constant-current driver that seems nearly perfect; the AMC7135.

Back up a hair. LEDs are current devices. Once forward voltage is achieved, current flow will increase near-logarithmically over only small increases in voltage; a runaway process leading to overheating and breakdown. Thus current limiters are needed.

The most basic is a series resistor. Basically, the resistor is chosen so that the current across it (calculated assuming the voltage drop across the LED is constant), is the same as that desired for the LED. Pick the right resistor, the loop current remains under the limit. The problems are two; all the voltage above the necessary forward voltage of the LED is transformed to heat in the resistor, and, the resistor is only of the correct value when the voltage is stable.

The better regulation is essentially a transistor that uses the current flow in a feedback loop, thus holding the current at a desired point. With the right components, these circuits will compensate for a range of voltages and, as well, react thermally in the correct direction to compensate for the changing behavior of LED and circuit as it warms up.

However, the typical packages I was finding were a couple bucks each and required up to a dozen external discrete components; capacitors, resistors, signal diodes, zener diodes, even inductors. Which was a lot of parts to be adding to a small board especially when I wanted to control three channels or more of LED.

But the AMC7135 is the ticket. Unlike many current limiters, it is preset internally to 350ma. It requires essentially no external components. And it may be a usage that's out of spec, but it can be successfully PWM'd. There are in fact high-end flashlights that use this exact circuit.

Again to step back; LEDs require a minimum voltage, and when this voltage is achieved will consume as much current as you let them. This makes them poor candidates for resistance dimming. The best way to control their intensity is to turn them on and off quite rapidly. By varying the ratio of time on to time off, you achieve a nice control of intensity.

Do this to red, green, and blue LEDs and you can achieve a decent range of colors as well.



Which is what I've been trying to do for over a year; to create an extremely cheap, small, high-power colored light that can be used inside props, on costumes, and in other theatrical applications. There are a lot of commercial packages that are similar, but few offer two of the things I find important for this application; tight control, and battery power.

Control turns out to be the sticky issue. What I really don't want is all those cheap LED toys; things you have to hold down a button and scroll through different colors to get to the one you want. This is non-optimal for theatrical use. It should be able to be set so when the actor (or the light board operator) hits a switch it lights up the right way the first time.

Proof-of-concept; ATtiny controlling two channels of a 3W LED via darlington transistors, on a 4xAAA battery pack. When you hold down the button it does a candle flicker.

There are also commercial products that allow you to dial up a preset -- from infrared controllers to full DMX-512 wireless solutions to the pretty-durn-close BlinkM. Where all but the BlinkM fail for me is that they are fiddly (or expensive). We don't want a lighting controller gaff-taped to a nearby wall with sticky tape pointing at the right preset. That's just another kind of over-complicated work around. Again, we want a user-programmed preset. After the light is set, it just plain turns on.

The only real failings of the BlinkM for me is lack of power for theatrical use, and some lack of flexibility in the existing controller software. Which might just be a conflicting paradigm thing (they went with a drum machine model for animations, I went for a flexible event-based system for mine).

The BlinkM from ThinkM.


So...I've had the high-power, hard-programmed RGB working. I had it on a costume in a show, and over the show it did exactly as required. The problem is, setting the desired look was a programming task. It was done with the skills, the knowledge of the circuit's behavior, and the programming tools I own.

The "Wiz" jacket, switching between free-running light animations when commanded remotely from the simple GUI shown on the laptop beside it.

What I want is for anyone to be able to purchase a kit or make the open-hardware light, set it to a theatrically useful look (oil lamp, say), and be done with it. But I am having no luck making the power I desire accessible to the end-user I envision.

Also, on the hardware side, if I make each individual light capable of simple stand-alone programming, it increases the unit cost. It makes too much sense to offload as much as the hardware as possible even if that does mean the end-user needs a minimum of two things to get started instead of one.



Hardware USB is the most transparent option. To put it on each individual light, though, increases their cost excessively. Plus the varied solutions are non-optimal in different ways. USB is a complex protocol, and there are no all-platform open definitions for producing a virtual COM port from it -- which is what is needed to allow one to write a nice user-friendly front-end (or even to surf in to the device via Terminal and program it on a command-line basis).

The older Arduinos used a translator chip from FTDI to handle interface to the user's USB port -- which also required a driver to be installed to show up on some platforms. There are AVR chips that are USB-native, but like the FTDI they are surface-mount devices and add considerably to the cost and effort of putting together each light.

HID is actually a lot easier; you can get a class-compliant HID with out-of-spec modeling of proper USB behavior, and it will still be recognized by most computers as a keyboard. There is even a clever hack that translates extra characters on this virtual keyboard into a fake serial port. But it requires multiple pieces of helper software and probably doesn't work on Mac yet.

Clever Arduino compatibles like the Trinket get by because the programming port used by avrdude is not per se a serial port. Basically, you can program an AVR using another non-USB compliant AVR (or even program itself with a clever enough bootloader) but it can't be made to show up as a serial port.

So, unless I want to write a wrapper for avrdude that presents a simplified GUI to the end-user but invokes the avrgcc toolchain behind the screen (too many pitfalls there I'm afraid), the best option is to move the expense of this USB-to-serial translation off the light and into a second board.

The BlinkM does it quite cleverly. It is programmed via a I2C connection, which is done using the soft serial code on an Arduino. Simply put, you plug the header of the BlinkM into matching pins on an Arduino header, run the provided Arduino sketch to turn the Arduino into a I2C to USB translator, then run the BlinkM programming software.

Somewhat similarly, you can once you have the complete Arduino software up and running, use an Arduino (with or without invoking soft serial -- in the old days it was done just by prying the ATmega itself out of the socket) to patch you though to the AVR you want to program. You could even use the Arduino IDE to write and upload the program.



And that's what I'm going to do. Only with an additional wrinkle. The power user can and should write their own software into the light. But for someone who just needs to specify the exact color it boots up into, or how long it takes to fade out when turned off, I am going to provide a space for user presets in non-volatile memory. So the end-user will use either FTDI cable (which are widely available in Arduino circles), or an Arduino with the appropriate software, to plug into the light node. They will try out different looks and then commit the look of their choice to one of the slots of user memory.

If and when I get that far, I can wrap this in a proper GUI. But before then, this behavior of going direct to looks or presets and setting the boot preset is also exactly what I want for inter-node communication.

Because the other thing I want to put on these lights that doesn't exist in any cheap, easy-to-use, prop-and-theater-friendly option is remote control.

The proof-of-concept for a accelerometer-based effect; this combined accelerometer, XBee module, and AAA battery pack to detect a throwing gesture and play a sound effect from a remote receiver. 

At the base of it is a protocol to let each node communicate bidirectionally. I'm doing it this way, instead of using existing buses like I2C, for transparency as I program. The BAUD rate I envision may be low, but I can still afford to send ASCII nouns rather than cryptic hexadecimal sequences.

I envision a complex prop that might have several lighting nodes each playing canned animations in free-running mode, and a single controller just telling them when to switch on and off. This is also how we will interact wirelessly; you won't control a candle flicker in real time, you will command it to light, then blow out.

A sticking point at the moment is the RF option itself. I'd like to provision each lighting node with the basic circuitry, omitting only the expensive transceiver. But between level shifting and LDO and of course a couple status lights, it may add too much to the individual cost and complexity.

This is worse when considering the transceiver options. Now, there are a lot of cheap, off-the-shelf 434 kHz, Bluetooth, etc. options. But all of them are inadequate for theater. They offer fifty feet of transmission in line-of-sight. Theater requires shooting two hundred and fifty feet through set walls and a fifty-member dance ensemble.

The leading options I have now are the Hope RF chips -- particularly the RFM69W and HW chips -- and the XBee series.

Trouble is, the Hope chips appear to require four digital pins to communicate with them properly, and the code to navigate their communications protocol eats up a full 8K of program memory. Which makes them pretty much impossible to run from an ATtiny, and pushes them up into "requires a late-model Arduino to operate" territory.

The XBees are simple and transparent and I've been using them in actual theater situations. Their major drawbacks are frequency and price. They are 2.5 GHz devices, and shorter wavelength radio has poor penetration of obstacles. The "Pro" models, which have the necessary power to punch from light booth to backstage, are upwards of forty bucks each.

So down the road, I hope to get the Hope chips working for me, but for now I'm going to have to hope that only a few of the more expensive transceivers are needed by the typical end-user.



And as for interfacing with the worlds of DMX-512 and MIDI; I'm holding off there. I see this as happening via software (aka a laptop with a DMX-512 dongle) even though it would be a lot more turn-key if it was a single stand-alone DMX-512 module. But getting one of those up to spec and robust, it would end up costing pretty close to the commercial models that are already available. So not really something I need to explore at the moment.



But, at last, I'm nailing down the specs on the basic light module. I should be able to get the first order out to the fab house for printed-circuit boards this week. Maybe even assemble one in time for my coming lighting design.

Here's the major parts. Power supply 3.7V to 5v; aka lithium poly, 5v wall wart, or 3x "penlight" batteries (AA or AAA). The latter is my preferred choice for theater due to the ease of swapping in freshly-charged cells (rechargeable or otherwise).

I have a bunch of 3W RGB's to start with, but I've found RGBW's available for about twice the price and those will provide a much nicer mix for typical theater applications (candles, lanterns, headlights...) Unfortunately RBGA or RGB+ "Warm" White (4,000 K) are harder to come by at budget prices.

The buck driver on the right there is there to illustrate mostly the SOT-89 surface-mount footprint of the AMC7135's, of which I'll be provisioning four of. A nice additional quality of these things; you can run them in parallel to drive higher wattage LEDs.

The controller chip looks at this point to be an ATtiny 20-pin, probably the attiny861A because of its 8K of program memory. I do love the 25/45/85, but there just aren't enough pins. Even the ATtiny84 is pushing it for sufficient pins -- and doesn't have the nice UART of the larger, more expensive chip. The various chips to the lower left are standing in for that footprint. I'm going through-hole and socket for ease in assembly and replacement.

I haven't decided on the header; whether to go with the 2x3 ICSP type or the 6-inline format shared by the FTDI cable and other similar devices. And I'm still pondering whether the XBee will be on the main board or have a daughterboard (for which the Adafruit board at the top right is standing in). The trade-off, as always, is between a compact footprint and lots of out-of-the-box functionality, versus price per item. Because I have to anticipate situations in which you'd want a dozen of these things scattered around as part of a more complicated lighting effect, and that would be a lot easier if I could keep them under $10 each.

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...

Hope

I've been looking for a while for a better option than the XBee for theatrical use. The XBee modules are fantastically easy to use -- basically, they are the Arduino of the wireless world. But they are also expensive. Even eBay sellers can't get you below $20 a unit.

The other downside is indoors range. The higher the frequency, the worse the reflections, and the 1mw standard XBee can't reliably get from one room of my apartment to the other. And you can't count on having good line-of-sight in theater. The XBee "pro" model increases this output power substantially, and can brute-force a signal all the way from booth, across the stage, and into the dressing rooms (which I've verified by using it in actual performances). But this option is also costly, raising the price per module to nearly $50.

The trouble with finding wireless options for theater is the combination of range and necessary reliability. We can't afford dropped signal if that is triggering a key effect. And the majority of bluetooth data links down to cheap keyfob transmitters are designed to operate at, maybe, 25 feet.

Well, there is a series of modules out there. The RFM69 series from HopeRF are under ten bucks each, even for the 100mw RFM69HW model. There are even (nascent) Arduino libraries for these increasingly popular modules. They do lack the ease of use and existing infrastructure of the XBee, but this seem the better choice.

The combination of high power and low frequency makes for better indoors range. And the low unit cost means I can incorporate remote control as a viable option to the DuckLite.



I've been looking a lot at parts costs, and with Chinese RGB modules, the cheaper MOSFETs for power switching, and ATtiny chips -- or, at least, using ICSP headers instead of incorporating a USB option -- I can get the unit price down to not much over $10 a light module. This makes it plausible to use them in multiples in a stage production; to have a set of lanterns or party lights or tea lights or costume lights or whatever.

The downside was going to be that the cost of controlling them remotely was going to be prohibitive, enough it was almost not worth adding the option even as an unpopulated set of headers. But with these nodes, this might return to being a viable option. With the realities of interface, power management, CPU support, physical headers, and so on they should roughly double the price of the modules, but this still seems plausible.



It also means all the work I've done so far in laying out the new PCB is a waste. Back to the drawing board on that one!

Repairs

A large part of my gear is getting rented this weekend. I also looked over the french scene breakdown of the next show, and I need more channels than I have at the moment.

So far the only soldering I've finished today is fixing a Blue Snowflake I got as a gift. Which, I am sorry to have to say, has some piss-poor engineering inside it. I understand necessary compromise, and how process will make unforeseen changes, but who would feel good signing off on this one!

Here's the problem. Daughterboard holding the mini USB connector. That makes sense; put the stress there, use that to screw to the chassis, have the electronics snug into it. The main circuit board, though, is suspended on two 3-pin headers. Which means it wiggles, and you get poor USB connectivity. After I'd reheated all the solder joints from USB jack to main circuit board, I re-assembled, and then put a couple drops of hot melt glue in to keep the thing from rocking back and forth on the connectors and breaking connection.

The boards are notched to go around the swivel nut that connects chassis to frame. And somehow, the USB was put in at about a 17-degree angle to the notch. Which means, when the board is assembled and installed, the swivel nut misses the notch entirely, and is all but jammed into the connector to the actual mic capsule. It makes it extremely difficult to finish the assembly without knocking out the connector (or tapping the circuit board off it's precarious balance on its headers.) Broken? I'm surprised the thing actually survived being shipped in working condition!




A vaguely similar problem besets my Sennheiser belt packs. The pack usually ends up strapped close to an actor's body, often in the natural curve of the small of the back. The microphone element is connected to the transmitter with a 1/8th TRS locking connector (expensive little things; I'm paying almost $12 each). The length of the connector means lots of leverage on the jack, causing several problems; the connectors unscrew, the wires break inside the plug, and the jack itself snaps off inside.

The latter is a pain because the circuit board is crammed with surface-mount components. The last one, I repaired by carefully cutting the broken jack to ribbons and then individually de-soldering the remaining scraps of the legs. The one previous, I tore the traces off the board trying to lever it out, and that means that whole unit has to be shipping back to Sennheiser for repair.




Despite these directly job-related repairs, I also have many of the parts from my Duck Node experiments spread out on the work bench as well. I want to have something ready for whatever comes up on the next production, even if it is another hand-soldered prototype instead of a proper board. Tangentially related to this, I'm going to be doing a soldering project with my youngest niece this Friday; a 4x4x4 LED grid from Seeedstudio. Which is also intended as a gateway drug into programming.

From the top, this is my wireless EasyButton (which may or may not currently have a configured XBee in it -- I keep switching the things around). Then an Arduino Trinket from Adafruit; a more-or-less Arduino-compatible board based around an ATtiny. I've been thinking about it for the DuckNode because it offers built-in USB programming for under $10. But it is also severely limited in the number of I/O pins, plus the USB bootstrapper is fragile (hence the festoon of wires on it now; those are programming leads). So bumping up to over $20 for an Arduino Mini probably makes more sense.

In the lower right is an abandoned proof-of-concept for an ATtiny-driven 3W RGB. It is being switched through power darlingtons, with hefty (1 watt) ballast resistors. Why I wanted to go for the more efficient constant-current drivers. And on the left is a proof-of-concept for the DuckNode concept, along with the wrist holster; an accelerometer paired with an XBee. For my tests, I parsed the output of the accelerometer in a Processing application, and fired off a sound cue when it crossed the right threshold.

The problem here...and why the project got suddenly so much more complicated...is very few accelerometers will output in analog that can be easily patched through to the ADCs on an XBee. I haven't seen a single one of the integrated accelerometer/compass units that wasn't digital (usually I2C). And that is such a pain to interface with XBee you are better off parsing through a microprocessor and handing that data off in a serial stream to the XBee. Which is also more power-efficient.

And, yeah; XBees are expensive, have a large footprint (relative to some other radios), and they (like a lot of electronics) are moving...from the Series 1 I own, to Series 2 -- both of which are deprecated in favor of the (much less useful to me) Zigbee protocol. But all the other options take time to learn and develop around. I already know the XBees. And I've used them in real stage conditions.



Sigh. And I also have to cut down the cords (they are too long and thin to be safe to use) on some chorus microphones before Saturday, where I'll be tacking them to the unistrut with zip ties. I filled several pages of notebook trying to come up with a combined unistrut bolt and shock-mount mic clamp for them that I could machine up myself, but no luck. Which means my first milling project may indeed be the Jubal Early.

Which is also going slowly. I'm finally getting a grip on how the parts fit together, but that meant throwing away the first attempt at a poly model. Arg. This would make so much more sense in a proper CAD, or at least in a modeling application that was more parametric. Carrara is not a NURBS modeler. What you build is what you get (aside from the option of tessellation -- but that tool has extremely limited options and tends to make a mess of models).

I really, really need to get comfortable with Blender, but out of all of the things I'm constantly having to learn and re-learn, software is the slowest and most frustrating of all of them.

Vee Hick Cull

The "Morrow Project" XR311 print arrived from Shapeways. It looks real good, even in the cheapest of the available materials (the white nylon). I didn't expect the tread on the tires to show as well as it does. In any case, I'll post some pictures once it gets assembled and painted up.

I'm pushing on contract and hourly right now, as bills are coming due and the next show doesn't go into tech for several weeks yet. So not a lot of time for props or electronics projects.



Successfully replaced another jack on a Sennheiser body pack. It's a pain because the circuit board is so tight, and the traces are fragile. I had to carefully cut apart the old jack with dykes and de-solder the stubs of the lugs one by one. I have at least one more to go through, plus the easier tasks of antenna and LCD, but the big labor is a pile of damaged Countryman B3's. I'm hoping I can return at least some of them to service, but they are all aging.

I may have imagined it -- no way to do a double-blind -- but when I finally washed out the elements the principals were wearing on Shrek, it made a big difference to the sound. Yes; you can actually rinse the Countryman elements in water. Or in alcohol, which is what I do. Do give them time to dry out properly, though!



Meanwhile, the crazy budget system I assembled at another theater made it through the first Theater Camp without problems. I still need to label and document. Downloaded a couple of installation diagramming software packages, but the level of detail I need for these end-users means I'll probably have to do the docs in PhotoShop. Or Inkscape, which is the shareware option to Illustrator.

A Rolls MA2355 is fed by a dedicated microphone (Crown PCC160) and drives two legs of monitors; one in the booth, another in the dressing room. This is completely independent from everything else, but at some point I'd like to link it up to the ClearCom for Stage Manager announcements to the dressing room. (This may be as simple as a length of cable).

The primary system aggregates through a Rolls rack mixer; this pulls in a pair of inputs dedicated to the FOH mix position, a pair from the firewire interphase of the sound effects computer, and front-panel jacks for iPod and dynamic mic for use during rehearsal and by the Theater Camps. On the remaining work list is to cut a plexi shield that will deny access to anything other than the latter two inputs to casual users of the space.

This feeds a DriveRack PA+, which does the absolute minimum system tuning; a little notching in a graphic EQ for gain, a gentle corrective parametric EQ, and delay for the rear speakers (which I'd like to replace, and move further forward to make proper fill speakers out of).

I've also got another rack mixer in there which is not yet connected, but is designed to bring together a second pair of firewire outputs with a second pair of feeds from FOH, to allow both access to the front fill stage monitors.

Still, just this (plus putting in hardwired boxes for the ClearCom runs, adding a Furman to the rack, and a few other details) already cost over fifteen hundred. The bucks add up quickly with sound.



Those bucks went to the theater. My own bucks stretched just enough to pick up a little fabric and repair my futon cover, but not enough, yet, to have any PCB's fabbed off. My browser is still filled with tabs on power MOSFETS and 5-watt LEDs, but that project is going to remain stalled for a little longer.

But Soft, What Ware Through Yonder Window...

I come today to sing praises to a few bits of useful software. At least, useful to a Mac-oriented, very much budget, sound designer and technician.


Wireless Workbench As of version 6, this has become fabulously useful software regardless of what brand of microphone you use. No longer do you have to use the nearest approximate Shure range; it has the profiles of every major line already programmed in. It has been redesigned in other ways, too; it is now vastly easier to fix one bad frequency, or generate a couple new compatible frequencies within an existing line.

If there is a downside, it is that it is too well supportive of systems I can only dream about; much of the software is oriented around automated scanning, remote updating and monitoring, and so forth. And that makes parts of the software a steeper learning curve than they might be.

Oh, yeah; what is it? It is free software from Shure that lets you coordinate frequencies of all of your wireless microphones, including mapping around interference sources, and checking for potential interference between microphones (the dreaded intermods).



Reaper With a price so low as to be practically free, and an incredibly open, transparent, and manipulable framework, this is now the preferred sequencer/DAW for the creating of complex sound effects. The downside to Reaper is that it is so new in how it thinks, the learning curve is -- again -- rather steep.

Like PhotoShop, there are usually several different ways of doing things. It is also optimized towards being very, very fast to work, and that can be a downside if you can't hold all the gestural commands and contextual options in your head, or lose concentration. It is rather like driving a sports car, in that it is so fast and responsive it can also get away from you if you don't pay attention.

There are still ways it has of organizing things that I quibble with, but I quibble silently; because it has been my experience that there is probably an alternate to each method already in the program and I just have to keep searching for it.



Audacity Open-source, extensible, freeware. Seeing a trend yet? You can create a whole cue in Audacity, but where it shines for me is in quickly trimming and normalizing samples, also in clean import and export in the variety of formats sometimes necessary (including but in no way limited to exporting mp3's with a fine degree of control over the encoding, and multi-track WAV files that can be used for massive multitrack effects in QLab.)

Audacity ships with so many tools it is easy to get lost in them. I've lately been using the noise reduction tool. One issue I have with Audacity, and why so much of my real sound manipulation is being done in Reaper, is that Audacity comes out of a more command-line approach. You punch in numbers and run an effect off-line. I prefer to apply an effect in real time and play with the knobs while I listen.



Qlab Okay, I'm a bit on the fence here. It used to be an extremely affordable, low-profile program that did one thing very well. Now it is adding bells and whistles to justify a price that is climbing all the time. It is still the most efficient and flexible multi-track multiple-polyphony playback engine there, capable of running a complex linear sequence as well as presenting non-linear material (and integrating in various ways with other equipment.) But for the latter, Max/MSP is vastly more flexible, and costs no more.

No, Duck Light.

I've been having a heck of a time parameterizing a potential kit here.

It starts with the problem of a kerosene lantern. This is a prop that shows up on stage in various productions. Since we don't of course want to actually set fire to lamp oil, the usual trick is flashlight bulbs and batteries. For a brighter "flame," a 12v halogen (automotive use) and a battery pack of high enough voltage to run it (such as 8xAA batteries).

The more robust solution is LEDs. At the simplest, you could, indeed, use one of the automotive-use amber LED arrays and hook that up to your 8-pack of batteries. It would last longer with a higher average output and more consistent color temperature.

Or you get a little fancier. Use a 3W RGB LED, like the Cree I've been having fun with of late. With PWM control, you now have a portable light that you can set to a selected color and intensity. And you can even flicker it.




Now, sure, you could just hard-wire a Cree, plus PWM if wanted, onto a piece of perf. I have one around I was building for an effect that got scratched. But it is a neater circuit if you have the board printed.

And even neater than that if you have a reflow oven sitting around.

Doing it this way makes for a more compact and more reliable circuit. But the downside is that you aren't soldering something to fit just a lantern. Economies of scale become economical when there is, yes, scale. The development time of a circuit board pays off higher if the same board can be used for other things other than lanterns.

And this is the first problem I'm having.  What are these "other things?"

The light-up coat I made for The Wiz is very much a unique application. I've done tens of shows with a lantern in them, but only two with light-up costumes. Really, I can't think of any other common theatrical situation that I would be reaching for a plug-and-play portable light source on.

Perhaps a flexible point source for general lighting; the kind of situations where you have a doorway or other inconvenient shadow and you just want a little face light. I'm willing to believe that a little firelight in such things as campfires and stoves would also be calling for a small portable RBG source if such were available. And I can't help thinking that there must be magic wands and crystal balls that could use a light.




Because there are two other givens with the PWM circuitry that gives us RGB control and potential flicker. The first being program-ability. The second being control-ability.

It goes without saying that the portable RGB source can be easily switched on and off. But you could also dim up and down, or change color on command.

And if you an empty socket, or the right kind of header, than it also becomes remote controllable. And you are no longer dependent on an actor getting over to the prop to turn it on and off.




Here's where creeping featuritis really comes into play, though.

Assume the "board" is an ATtiny-based PWM/program generator with a couple of controller inputs (perhaps capacitance sensing to save on external hardware). Assume it switches an arbitrary load through a trio of Power Darlingtons (or similar) and solder tabs or screw terminals. This detaches the LED/load itself so the circuit can be hidden in the base of a lamp or whatever. Constant-current drivers would be better for LEDs but would have to be matched; this allows us to re-purpose for relays or other tasks.

The board can easily power-regulate from a 3v to 12v source, so a 3-pack or 4-pack of rechargeable batteries is good enough. But a lipo is sexier; high density rechargeable battery built in, with charging circuit and charge indicators, so all you have to do is plug it into a USB charger (or similar) between shows.

(The main downside to the lipo is if you have back-to-back shows with heavy use of the circuit. Using swappable batteries means you can put the device back in service without having to wait on a charge.)

The bigger problem is program-ability. For me, I'm fine writing new code as needed and feeding it through an ISP port. But it might be easier for the general user -- heck, it would be easier for me too -- if you could adjust the behavior on the fly via nothing more than a USB cable. Better yet, through a USB cable -- or remotely through a radio link -- via a GUI that dealt with most of the details of selecting colors and setting up switches and so forth at a higher level of abstraction than typing fresh code.



I think at some point, you have to accept that one "board" shouldn't try to be too generalist. Perhaps it makes most sense to design it as if it will always be PWM'ing three channels of LED, with a preset of several hard-coded behaviors selected by resistor ladder and/or transmitted commands. And re-purpose that hardware with scratch-written code as unique applications arise.

And to ignore such fun ideas as lipo charging circuits, boost converters, constant-current drivers, and so forth. And restrict the immediate flexibility to setting jumpers on the PCB, and the load and source that get attached to the screw terminals.

Maybe that is a build-able circuit. Maybe that's enough to boot up Eagle and see what it might look like...

LiPo and Buck-Boost and Xbee and Cree, These Are a Few of My Favorite Things...

I'm in production, working a 30-hour week for show calls alone (plus ongoing repairs and maintenance, meeting on the next two or three shows, etc.)


Plus I've really fallen behind on such things as house cleaning and car repair.  Plus finances are still not good, meaning I need to concentrate on work that pays instead of long-term development.

Still.

An upcoming show is going to use a lantern.  They seem happy to handle it themselves -- didn't even think of asking me -- but is a good excuse to continue the development I started back with my BlinkM experiments.  Especially since The Wiz showed I could make a battery-powered remote-controlled rig that PWM'd multiple channels of high-power LEDs.



The BlinkM board from ThingM is very cute; it combines a "Piranha" LED with an ATtiny controller.  They package it with an easy-to-use software that uses an Arduino as a programmer (or you can use another USB to serial converter, like my own favorite USBtiny ISP from Adafruit).


But it is underpowered for stage use.  Especially if you intend to actually light part of a scene with an oil lantern hanging in a barn, or a storm lantern in an actor's hands -- or something more unique like a glowing crystal ball or Wizard's Staff or whatnot, we really need to reach for the power of the Cree; several options in 1W LEDs, single-color and RGB.

Unlike the mere 30ma a channel of a Piranha, though, the 350ma of a Cree can't be switched by a naked AVR.  Plus the power-hungry nature of these things means you really don't want to be throwing half your battery life into cooking a 2W current limiting resistor.  The best option is an actual current-regulated supply, better yet, a buck converter that trims the voltage down to a useful level without throwing half the power away as heat.


The reason for all this complexity, of course, is that with a bulb and a wire (or even a high intensity LED and a wire) you are limited to static display.  With the embedded AVR, you can flicker like a candle, or pulse or change colors.  You can dim up and down instead of the light switching instantly to full power, which also makes for a more realistic effect.  You can adjust the color of the effect, and the intensity of the effect, without having to wrap gel around it.


And this level of control can be achieved remotely.  In the case of the WIZ's coat, via a laptop in the booth.  The simplest link (and one of few with the range for theatrical use) is the XBee modules.  Unfortunately they are also not that cheap, and have other electronic requirements.

Which brings me to the tangential "Duck Node" concept; small battery-powered XBee-enabled devices that can either be used to sense an actor's motions or other commands, or reversed to control an effect -- such as the battery-powered high-intensity lights we are talking about.


What I want to build right now, then, is a prototype lantern.  For the upcoming show, it would work just as well with a mono-color LED, a switch on the side so the actor controls it, and not even a flicker circuit.

But I'm going to give it the full bells and whistles; RGB LED, and full remote control.  The only trick at this point (since I have all of that working now on stage in another form factor) is getting it to fit inside an oil lantern.

If the prototype works out, though, I'll be able to custom-design the next circuit to be printed instead at a fab house.  And then I might actually have something to bring to the next Maker Faire....

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).

Wizardry

So now it is official.

I have several projects I've promised to work on, with a deadline already looming.

1.  Put LEDs on a hat.

2.  Put a strip light on voice control.

3.  Create a gestural interface.

4.  Keep working on my POV wand if I get time.


The first is a no-brainer.  My "Cree" 3W RGB's arrived in the mail, as did several meters of 6mm light pipe.  I can do this with some 1 watt resistors (I've learned THAT lesson!) but I'm holding out for the constant-current drivers I also put on mail order.  I don't have any strips or really many discrete LEDs, though.  I was pricing some nice 50ma greens in Pirahna style cases at Digikey, though.  But I think there's enough time to wait and see what the hat looks like before I have to make another shopping trip.

This might just be hard-wired.  The most complicated part of it might just be the power button.  But...I am fully prepared to go RGB with it, and do some chases or something.

At the moment I am lacking most of the "DuckNode" system I've been trying to design over the past few years.  Which is to say; I don't currently have a plug-and-play solution to send wireless control out to the stage and into a costume for an effect like this.

(The local Orchard Supply Hardware just got some vintage style oil lamps in stock.  I'm pretty strongly tempted to stick a Cree, an ATtiny implementation of my custom "blink" code, and an XBee for hand-rolled remote control into one of them.  Except the oil tank is small enough I'd probably want to use a LiPo for power, with a USB jack and a charging circuit.  And that makes this an $80 lamp....)



2.  I picked up an 8-channel EQ display chip, which should do just fine for a voice control.  Except it spits out analog data serially, which means you pretty much want a micro to control it, and I'm starting to run out of free AVRs (Arduino or not).  I may just have to solder up another protoboard with an ATtiny on it, and do more pretend-it-is-an-Arduino clone because I just don't have time to think my way through straight C and the AVR toolchain.

The tough part is controlling anything more than a strip of LEDs.  I've been reading up on triac dimming, and I'm really not wanting to do hasty work around raw AC.  So the best options at this point for controlling lights at line voltage are;

     a.  Power Tail.  This is a plug-and-play relay box for 15 amps.  At 10ms cycle time it isn't going to do PWM, but I'm willing to bet that timing a pure off and on is going to be close enough for a Dalek Eyestalk effect.

     b.  Cheap Dimmers.  American DJ type baby dimmer packs are as cheap as ninety bucks on Amazon.  Only four channels at a whopping 5 amps each, but it is a solid metal case and more-or-less UL listed.  Also the one I'm looking at will take a 0-10 analog control signal, which is easy enough to fake up with an external power supply and some TIP120's.

     c.  Learn to talk DMX.   It has been done on the Arduino, and there are even libraries.  It isn't trivial -- in several ways it is more messy than MIDI.  Of course, some packs you can talk to with MIDI as well but spitting a LOT of MSC (MIDI Show Control) at an ETC light board is a good way to crash the board and stop the show.  So, yeah...I'll pass on the odd MSC for a single effect, but trying to do a PWM-type effect that way would be even more stupid than wiring up my own TRIAC-based danger shield.


3.  And this one gets interesting.

I've already shown I can detect a punching motion (which is a possible "Tim the Enchanter" magic gesture.)  Not sure exactly how best to detect a snap of the fingers, if that's how the actor wants to go. 

Hold on.

Ouch ouch ouch.

Yes...I can detect the jarring motion of a snap of the fingers with an accelerometer mounted in a wrist band.  Or attached to a wrist with masking tape.  Ouch ouch ouch.

The tougher part would be discriminating -- better, specifying -- which of several DIFFERENT effects is to be triggered via pointing at them whilst gesturing.

The simplest solution is a compass.  Or, rather, a tilt-compensated triple-axis magnetometer.  Which aren't that expensive, but only talk I2C.  Which means I can't talk to those naked, either.  I'd need an AVR to read off the magnetometer chip, and then tell the XBee to transmit the signal to the interpreter.

Which in any case brings me squarely back to the DuckNode, and the Processing host software I have only begun to write.  (Current status?  I can select available ports on the fly, and recognize individual pin status).

Fortunately, #3 is completely stretch goal.  First I need to get that voice-activated light working on the breadboard.  Maybe I'll even dare some 120v relays -- just for a proof of concept, mind you.




Oh, and I realized something about the POV circuit.  The persistence of vision effect only takes place over 250 milliseconds.  But if a lighting effect is much brighter than the ambient light, you will also get afterimage.  Which can linger quite a bit longer.

In daylight, my POV circuit isn't particularly good.  In a darkened room, I "see" clearly a swath that crosses most of my body. 

So it is still plausible.  The next iteration I'm moving the LEDs closer together, find some way to diffuse them a little (they are a little too much brighter on-axis now), and increase their number.  I'm also finding that arbitrary patterns read better than words.  But at some point I really need to write a Processing routine that will turn a bitmapped image into a binary string, because I'm getting pretty tired of counting rows by hand as I manually type in 1's and 0's.

De-Bouncing

So you have this effect.

In a recent effects meeting, we were talking about a lighting effect attached to a costume.  If, we said, you put electrical contacts in the costume gloves, you could light the light by holding your fingers together.

That's clever.  It works well enough.  But make it two lights, and it starts to get complicated.  That's two gloves, two sets of contacts, and if the actor forgets themselves and presses their fingertips together...you've cross-circuited.  Which may be the all-purpose problem solver on Star Trek The Next Generation, but works out badly in the real world.

This is yes another case of being unable to uncouple in your mind the physical trigger (call it a button, or call it a sensor),  and the resulting effect.  If all you are using is basic circuits -- battery, light, switch -- then this is indeed how it works.  But...an awful lot of theatrical effects -- including lighting effects built into costumes -- are already complex effects.

Which is to say; they already include intelligence.  And if your costume or prop already has an embedded micro-processor chasing a string of LEDs or counting down on a 7-segment display, it is just plain silly not to break out another pin for control input.

And, actually, circuits are cheap. A switch needs to be mounted to something solid, and needs to be soldered in.  Solder in a stand-alone capacitance sensor breakout board, and you have a latching circuit for your light.  The same number of wires to solder, it is no more expensive than a good switch, AND it doesn't need a good surface to be mounted on.  And it has no moving parts to break or snag.

More discussion, and more rant, below the fold.  No circuit diagrams this time around, though.

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.

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.