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.
Showing posts with label Wiz. Show all posts
Showing posts with label Wiz. Show all posts
Sunday, May 22, 2016
Friday, September 13, 2013
A New Show, a Diagetic Onion
I'm in tech on a musical in a different building than usual. Different challenges, different approach. I thought it might be interesting to both elaborate and contrast.
The last show I did was "The Wiz." My artistic approach was presentational, even artificial; all of the music (from the live band), the singing, and the sound effects were summed together into a mono mix, which was presented at nearly equal volume to every seat in the house. There was no attempt at localization or worldizing, or even an effort towards separation.
In terms of effects designs, I made no pretense at diagesis. Even the sound of the twister was consciously an effect. Actually, consciously a musical effect; it was a synth patch performed live every night on a keyboard!
The vocal reinforcement was also artificial. Loud, obvious, with strong compression and plenty of reverb. There were additional vocals during many numbers, and for this the back-up vocalists were in full view of the audience and singing at close range into stand mics.
The show in tech now is "The Drowsy Chaperone." Which may be the only completely diagetic musical in the traditional style (I am discounting rock-format shows where all the songs are in-show being performed with the on-stage band).
Certainly, there are a number of musicals where characters are actually singing within the world of the play; "The Sound of Music," for one. "Singing in the Rain" for another. What makes "The Drowsy Chaperone" unusual is that every moment, every sound of the play within the play is explicitly meant to be coming from the on-stage phonograph.
The way I see it, there are two kinds of effects in the show. The effects within the external show -- the New York apartment of THE MAN IN THE CHAIR -- should be approached with utmost realism. The effects from within the musical he is listening to/imagining are just that; effects. They are whatever the people who committed the original 1928 Broadway production to shellac chose to include. Which makes them, in my mind, more presentational than real and localized in the same generalized sonic space as the singers and band.
Were I doing this show in a larger space, I think I would present that same mono mix of all elements, with only THE MAN IN THE CHAIR (and those elements of his world that interrupt the action) as localized (and hence diagetic).
The space I am in is compromised. It is very small, with a ceiling too low to allow center cluster or front fills. The actors are close, the band is backstage but loud. Oddly enough, the vocal reinforcement becomes subtle; it can't really be anything but, because the physical layout of the space only permits a few dB gain before feedback.
The equipment is also challenging. I have been spoiled at my other theater; the multi-speaker Meyer system is run by a central Galileo processor with cross-over, room equalization, corrective delays. And then we tweak further at the front end, via the digital console.
On "The Wiz" I had strong EQ notching in the main vocal bus, courtesy of the LS9's available 32-band graphics. I also tend to do a few other tweaks to seat the vocals properly. Plus, of course, individual tailoring of the sound of each microphone via the dynamics processing and parametric equalization available on every single channel.
I'm doing "Drowsy" on an old (non-digital) Soundcraft. Plugged pretty much directly into a pair of JBL Eons for FOH. For mics I have a mere handful of Sennheiser G2's, plus some chorus mics hung from the proscenium. (As is usual for the latter, I only get useful material from them when someone is standing no more than six feet away).
And this is where achieving simplicity becomes complex. Because the goal is simple; gentle reinforcement of the small number of body mics and some judicious area micing. The supra-diagetic nature of the show within the show means placement or localization is unimportant. Just push a little sound out, as seamlessly as possible. If the amplification is obvious, this isn't a problem; we don't really know what technology the recording engineers brought to play in 1928 and we can explain quite a lot as due to vagaries of the recording process.
But.
To get simple clean sound means the right mic and the right speakers for the space. And if you can't get those, then processing that -- with all of its compromises -- makes the mics you have and the speakers you have as clean and direct as you can achieve.
Because you are in a real world. A hall with distinct acoustics of its own, that the speakers interact with. This is why you have to tune the system to the house. And you can't do that with a naked sound board and a handful of gaff tape.
There were many and sundry odd things that apparently were tax write-off donations to the theater over many years. A Rane processor. Video router. A second board. Multiple firewire interfaces. The first on that list actually has the best long-term potential. It is unfortunately a Windows-only machine and even if I had the funds to put an emulator on my current laptop I don't have the time to get it all working.
So I turned to the last. Last night was the big experiment. And it worked well enough I think I will run with that for the run of the show.
Reaper.
As it turns out, the MOTU firewire interface I found lying in the basement has some nice onboard DSP. I'm using it for a low-end roll-off and a bit of compression, because it was hitting the inputs of my computer too hard.
And then I'm taking that signal in, and running the DAW in real-time. Mostly for the graphic, where I notched out almost excessively to wrench enough gain to make the proscenium mics worth using. Over the next few days I'm going to experiment some more and see if I can't split out a second bus for the wireless mic send.
The other tasks for the DAW are a small amount of delay, some limiting, better overall EQ tailoring, and perhaps a little reverb (at least on the wireless mics -- they sound more like they are in the space when they aren't completely dry).
On TOP of this scary bit of rig is QLab, feeding out the same firewire interface. Because the aesthetic of realistic sound within the world of the framing story -- the New York apartment -- requires multiple effects speakers.
There's a speaker hidden inside the cabinet with the phonograph. Actually, I tried the phonograph itself as a sound source and it was wonderful sounding, warm and real. But, alas, the old tube amp is aging and the capacitors are shot; after being run for twenty minutes it started to hiss and crackle in a way that would be unacceptable for the production.
On the other side of the stage, a cheap Radio Shack iPod speaker is hiding near the answering machine. This is both localization and wordizing; the speaker is small and tinny like the answering machine it is simulating, and it is in the same environment where it bounces off the nearby hard surfaces in a sonically distinctive way. Our ears are very, very good at hearing these nuances, and it adds immeasurably to the realism of a sound effect.
The phone is an actual dial phone. I had thought I was done with this forever, but just before I threw away my old Bell Labs generator this show comes along. (As it turns out, one of the other designers owns a Tele-Q, which is a very nicely engineered built-for-theater ring box). At the moment, I am ringing the phone with a button, and it is wired through the scavenged remains of some of the bad XLR I had to pull down during load-in.
My intent -- in the next few days I may have another report -- is to replace button with relay, stick electronics in between that will take a MIDI event as a trigger, and run a, yes, physical phone from QLab along with the rest of the sound cues.
The last show I did was "The Wiz." My artistic approach was presentational, even artificial; all of the music (from the live band), the singing, and the sound effects were summed together into a mono mix, which was presented at nearly equal volume to every seat in the house. There was no attempt at localization or worldizing, or even an effort towards separation.
In terms of effects designs, I made no pretense at diagesis. Even the sound of the twister was consciously an effect. Actually, consciously a musical effect; it was a synth patch performed live every night on a keyboard!
The vocal reinforcement was also artificial. Loud, obvious, with strong compression and plenty of reverb. There were additional vocals during many numbers, and for this the back-up vocalists were in full view of the audience and singing at close range into stand mics.
The show in tech now is "The Drowsy Chaperone." Which may be the only completely diagetic musical in the traditional style (I am discounting rock-format shows where all the songs are in-show being performed with the on-stage band).
Certainly, there are a number of musicals where characters are actually singing within the world of the play; "The Sound of Music," for one. "Singing in the Rain" for another. What makes "The Drowsy Chaperone" unusual is that every moment, every sound of the play within the play is explicitly meant to be coming from the on-stage phonograph.
The way I see it, there are two kinds of effects in the show. The effects within the external show -- the New York apartment of THE MAN IN THE CHAIR -- should be approached with utmost realism. The effects from within the musical he is listening to/imagining are just that; effects. They are whatever the people who committed the original 1928 Broadway production to shellac chose to include. Which makes them, in my mind, more presentational than real and localized in the same generalized sonic space as the singers and band.
Were I doing this show in a larger space, I think I would present that same mono mix of all elements, with only THE MAN IN THE CHAIR (and those elements of his world that interrupt the action) as localized (and hence diagetic).
The space I am in is compromised. It is very small, with a ceiling too low to allow center cluster or front fills. The actors are close, the band is backstage but loud. Oddly enough, the vocal reinforcement becomes subtle; it can't really be anything but, because the physical layout of the space only permits a few dB gain before feedback.
The equipment is also challenging. I have been spoiled at my other theater; the multi-speaker Meyer system is run by a central Galileo processor with cross-over, room equalization, corrective delays. And then we tweak further at the front end, via the digital console.
On "The Wiz" I had strong EQ notching in the main vocal bus, courtesy of the LS9's available 32-band graphics. I also tend to do a few other tweaks to seat the vocals properly. Plus, of course, individual tailoring of the sound of each microphone via the dynamics processing and parametric equalization available on every single channel.
I'm doing "Drowsy" on an old (non-digital) Soundcraft. Plugged pretty much directly into a pair of JBL Eons for FOH. For mics I have a mere handful of Sennheiser G2's, plus some chorus mics hung from the proscenium. (As is usual for the latter, I only get useful material from them when someone is standing no more than six feet away).
And this is where achieving simplicity becomes complex. Because the goal is simple; gentle reinforcement of the small number of body mics and some judicious area micing. The supra-diagetic nature of the show within the show means placement or localization is unimportant. Just push a little sound out, as seamlessly as possible. If the amplification is obvious, this isn't a problem; we don't really know what technology the recording engineers brought to play in 1928 and we can explain quite a lot as due to vagaries of the recording process.
But.
To get simple clean sound means the right mic and the right speakers for the space. And if you can't get those, then processing that -- with all of its compromises -- makes the mics you have and the speakers you have as clean and direct as you can achieve.
Because you are in a real world. A hall with distinct acoustics of its own, that the speakers interact with. This is why you have to tune the system to the house. And you can't do that with a naked sound board and a handful of gaff tape.
There were many and sundry odd things that apparently were tax write-off donations to the theater over many years. A Rane processor. Video router. A second board. Multiple firewire interfaces. The first on that list actually has the best long-term potential. It is unfortunately a Windows-only machine and even if I had the funds to put an emulator on my current laptop I don't have the time to get it all working.
So I turned to the last. Last night was the big experiment. And it worked well enough I think I will run with that for the run of the show.
Reaper.
As it turns out, the MOTU firewire interface I found lying in the basement has some nice onboard DSP. I'm using it for a low-end roll-off and a bit of compression, because it was hitting the inputs of my computer too hard.
And then I'm taking that signal in, and running the DAW in real-time. Mostly for the graphic, where I notched out almost excessively to wrench enough gain to make the proscenium mics worth using. Over the next few days I'm going to experiment some more and see if I can't split out a second bus for the wireless mic send.
The other tasks for the DAW are a small amount of delay, some limiting, better overall EQ tailoring, and perhaps a little reverb (at least on the wireless mics -- they sound more like they are in the space when they aren't completely dry).
On TOP of this scary bit of rig is QLab, feeding out the same firewire interface. Because the aesthetic of realistic sound within the world of the framing story -- the New York apartment -- requires multiple effects speakers.
There's a speaker hidden inside the cabinet with the phonograph. Actually, I tried the phonograph itself as a sound source and it was wonderful sounding, warm and real. But, alas, the old tube amp is aging and the capacitors are shot; after being run for twenty minutes it started to hiss and crackle in a way that would be unacceptable for the production.
On the other side of the stage, a cheap Radio Shack iPod speaker is hiding near the answering machine. This is both localization and wordizing; the speaker is small and tinny like the answering machine it is simulating, and it is in the same environment where it bounces off the nearby hard surfaces in a sonically distinctive way. Our ears are very, very good at hearing these nuances, and it adds immeasurably to the realism of a sound effect.
The phone is an actual dial phone. I had thought I was done with this forever, but just before I threw away my old Bell Labs generator this show comes along. (As it turns out, one of the other designers owns a Tele-Q, which is a very nicely engineered built-for-theater ring box). At the moment, I am ringing the phone with a button, and it is wired through the scavenged remains of some of the bad XLR I had to pull down during load-in.
My intent -- in the next few days I may have another report -- is to replace button with relay, stick electronics in between that will take a MIDI event as a trigger, and run a, yes, physical phone from QLab along with the rest of the sound cues.
Monday, August 12, 2013
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.
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.
Monday, August 5, 2013
Mono-Mania
Most of my theater work is basically mono.
There's no point to panning the wireless mics attached to actors. Even if you could track them across stage, the very reason for them to be there is so audience members sitting further away from the actor can still hear. Panning the reinforced sound towards where the actor really is would be antithetical to that goal. If anything you'd want to pan the other way!
More subtly, panning the band is sub-optimal. Reason being that in many houses, a significant part of the audience is covered by only one speaker. If you were to pan the second woodwind hard left, for instance, half the audience would hear too much flute in the final mix, and the other half would hear too little.
You can pan a little, depending on the house, and this can help to open up a congested mix. But it is something best done in moderation, with an understanding of the compromises that may result.
In relation to that, one trick for getting vocal clarity (particularly important and difficult in underscored dialog) is to send the wireless reinforcement of the actors to one set of speakers, and the band reinforcement (or for some shows, the pre-recorded backing tracks) to another.
This leverages the Cocktail Party Effect: the way the human brain is able to sort out one specific voice from the surrounding noise...if given localization cues.
In smaller houses, the direct acoustic energy off the stage is your friend here. If the first impulse that arrives at the audience member's ears is from the actor on stage, this helps their brain sort out the dialog they are trying to follow from the surrounding energy of band, ensemble, sound effects, and general stage noise.
Making this even more useful is what is called the Precedence Effect or sometimes the Haas Effect. This is another aspect of the built-in human signal discrimination; localization occurs upon the first impulse if it is within a few dB (up to -10 dB in fact!) of a stronger but later signal.
What this means, is if your reinforcement signal chain is delayed by 5-15 milliseconds, the audience members will perceive the sound as coming from the actors, not from the speakers. Even if the speakers are louder than the actors!
Tangentially related to this is the Broadway anti-flanging trick of sending each actor in a duet to a different signal chain; the so-called "A-B" reinforcement method. This reduces the disturbing sound that arises when an actor is getting picked up on two different microphones at the same time (a situation that arises far too often in the romantic plotlines of the golden-age musical).
However. However. Of late I've been doing a number of musicals that are more akin to the Brill Building than to Broadway.
This takes a little explanation. For a classic like "Oaklahoma!" the illusion is that we are out in the wide-open prairie with Curly, Laurie and Judd. Orchestral music swells in the background, and the people sing to us from where they stand on stage.
For a musical like "The Wiz" the illusion is of a Motown studio session. Loud, compressed, artificial sound, band and effects and wireless all rolled together in to a single seamless mono mix.
The main advantage this gives me is that I don't have to try to taper my reinforcement speakers to try to mimic the inverse-square falloff of the acoustic energy from the stage. Instead I am running a hot system that blasts right over the stage, and is essentially flat from the front seats to the rear of the theater; every seat, therefor, hears the same show.
It also means the whereas for a show like "Sound of Music" I took every chance to back off the reinforcement into naturalistic, near-invisibility, for this show the dialog is all run hot as well. There is less of a division between song level and dialog level.
(However, this still doesn't release the FOH mixer from being conscious of the tendency for levels to rise. You have to watch yourself, watch the meters, and consciously back down at intervals lest you end up having the system peaking well before the 10:00 number.)
(This bears expansion. When you run hot, hearing fatigue sets in. It sets in on you, on the audience, and even on the band and actors. Even if your system could keep going up and up indefinitely -- if you had unlimited headroom and there was no such thing as feedback -- you rapidly reach a point of not just diminishing but paradoxical returns. With every increase in volume, hearing fatigue increases faster and the sound becomes perceptually softer and more dull-sounding. This process continues to accelerate until the audience is temporarily deaf and nothing you can do will help them hear the nuances of the next piece of dialog. So watch those meters, check your own assumptions frequently, and take every chance offered by a slow scene or a soft song to back down again. And then you will have the reserve power for those show-stopper numbers.)
I'm also, for the first time in this building, running without delay.
Usually I have up to 40 milliseconds delay on the reinforcement, leveraging the Precedence Effect to make the actors on stage the apparent source of all the audio energy. In this case, I have no delay other than the physical distance (and the corrective delay between the different speakers of the multi-speaker setup). The reinforced sound is the first thing to hit the audience, and all the noise from the stage and all the leakage from the pit orchestra follows in time.
And that I think has given me an unusual clarity for this house. By presenting the reinforced sound to ears first, they are able to get crisp, time-aligned waveforms. The smear of sound propagated acoustically from the stage falls behind that first peak.
As part of this philosophy, I've been doing a lot of effects designs that are similarly presentational.
In a realistic effects design, we pan towards where the sound is supposed to be occurring. Actually, this is just the start. We set up specific and unique speakers for effects. We position speakers carefully to allow their sound to "Worldize" into their environment (a toilet flush sounds best, for instance, if you put the speaker in the part of the set that is standing in for a bathroom, and let the sound echo in a natural way around the set walls).
I've gone further, using bell ringers to make an actual phone ring on stage, putting speakers into an intercom box, even once using a live walkie-talkie on stage.
For a presentational effect design, the overarching concept is that what we hear as an audience is non-diagetic.
(The story is told by I think Alex North, who was asked by Alfred Hitchcock during the filming of "Lifeboat" where the orchestra was supposed to be in these scenes out in the middle of an ocean in a lifeboat away from everywhere. The composer asked the director, "Where are the cameras?")
Anyhow, look no further than film or television comedy for non-diagetic sounds. We don't suppose the "Waa waaa" trombone is actually in the scene! (At least not mostly -- there are a number of classic comic moment when what was assumed to be non-diagetic turns out to be quite "real" -- at least to within the fluid reality of a comedy.)
So you conceive of sounds that reinforce the action or the emotion but aren't pretending to be the actual sounds of some actual thing on stage. But even when the sounds are natural to the environment being presented, I have been tending in many of my recent designs to present them as part of the total mix going out the speakers. Instead of sending an effect to stage speakers and pretending there is a pirate ship on stage, I send to the mains along with the orchestra and pretend we are watching a show that is presenting the idea of a pirate ship.
Sounds subtle, I know!
There's no point to panning the wireless mics attached to actors. Even if you could track them across stage, the very reason for them to be there is so audience members sitting further away from the actor can still hear. Panning the reinforced sound towards where the actor really is would be antithetical to that goal. If anything you'd want to pan the other way!
More subtly, panning the band is sub-optimal. Reason being that in many houses, a significant part of the audience is covered by only one speaker. If you were to pan the second woodwind hard left, for instance, half the audience would hear too much flute in the final mix, and the other half would hear too little.
You can pan a little, depending on the house, and this can help to open up a congested mix. But it is something best done in moderation, with an understanding of the compromises that may result.
In relation to that, one trick for getting vocal clarity (particularly important and difficult in underscored dialog) is to send the wireless reinforcement of the actors to one set of speakers, and the band reinforcement (or for some shows, the pre-recorded backing tracks) to another.
This leverages the Cocktail Party Effect: the way the human brain is able to sort out one specific voice from the surrounding noise...if given localization cues.
In smaller houses, the direct acoustic energy off the stage is your friend here. If the first impulse that arrives at the audience member's ears is from the actor on stage, this helps their brain sort out the dialog they are trying to follow from the surrounding energy of band, ensemble, sound effects, and general stage noise.
Making this even more useful is what is called the Precedence Effect or sometimes the Haas Effect. This is another aspect of the built-in human signal discrimination; localization occurs upon the first impulse if it is within a few dB (up to -10 dB in fact!) of a stronger but later signal.
What this means, is if your reinforcement signal chain is delayed by 5-15 milliseconds, the audience members will perceive the sound as coming from the actors, not from the speakers. Even if the speakers are louder than the actors!
Tangentially related to this is the Broadway anti-flanging trick of sending each actor in a duet to a different signal chain; the so-called "A-B" reinforcement method. This reduces the disturbing sound that arises when an actor is getting picked up on two different microphones at the same time (a situation that arises far too often in the romantic plotlines of the golden-age musical).
However. However. Of late I've been doing a number of musicals that are more akin to the Brill Building than to Broadway.
This takes a little explanation. For a classic like "Oaklahoma!" the illusion is that we are out in the wide-open prairie with Curly, Laurie and Judd. Orchestral music swells in the background, and the people sing to us from where they stand on stage.
For a musical like "The Wiz" the illusion is of a Motown studio session. Loud, compressed, artificial sound, band and effects and wireless all rolled together in to a single seamless mono mix.
The main advantage this gives me is that I don't have to try to taper my reinforcement speakers to try to mimic the inverse-square falloff of the acoustic energy from the stage. Instead I am running a hot system that blasts right over the stage, and is essentially flat from the front seats to the rear of the theater; every seat, therefor, hears the same show.
It also means the whereas for a show like "Sound of Music" I took every chance to back off the reinforcement into naturalistic, near-invisibility, for this show the dialog is all run hot as well. There is less of a division between song level and dialog level.
(However, this still doesn't release the FOH mixer from being conscious of the tendency for levels to rise. You have to watch yourself, watch the meters, and consciously back down at intervals lest you end up having the system peaking well before the 10:00 number.)
(This bears expansion. When you run hot, hearing fatigue sets in. It sets in on you, on the audience, and even on the band and actors. Even if your system could keep going up and up indefinitely -- if you had unlimited headroom and there was no such thing as feedback -- you rapidly reach a point of not just diminishing but paradoxical returns. With every increase in volume, hearing fatigue increases faster and the sound becomes perceptually softer and more dull-sounding. This process continues to accelerate until the audience is temporarily deaf and nothing you can do will help them hear the nuances of the next piece of dialog. So watch those meters, check your own assumptions frequently, and take every chance offered by a slow scene or a soft song to back down again. And then you will have the reserve power for those show-stopper numbers.)
I'm also, for the first time in this building, running without delay.
Usually I have up to 40 milliseconds delay on the reinforcement, leveraging the Precedence Effect to make the actors on stage the apparent source of all the audio energy. In this case, I have no delay other than the physical distance (and the corrective delay between the different speakers of the multi-speaker setup). The reinforced sound is the first thing to hit the audience, and all the noise from the stage and all the leakage from the pit orchestra follows in time.
And that I think has given me an unusual clarity for this house. By presenting the reinforced sound to ears first, they are able to get crisp, time-aligned waveforms. The smear of sound propagated acoustically from the stage falls behind that first peak.
As part of this philosophy, I've been doing a lot of effects designs that are similarly presentational.
In a realistic effects design, we pan towards where the sound is supposed to be occurring. Actually, this is just the start. We set up specific and unique speakers for effects. We position speakers carefully to allow their sound to "Worldize" into their environment (a toilet flush sounds best, for instance, if you put the speaker in the part of the set that is standing in for a bathroom, and let the sound echo in a natural way around the set walls).
I've gone further, using bell ringers to make an actual phone ring on stage, putting speakers into an intercom box, even once using a live walkie-talkie on stage.
For a presentational effect design, the overarching concept is that what we hear as an audience is non-diagetic.
(The story is told by I think Alex North, who was asked by Alfred Hitchcock during the filming of "Lifeboat" where the orchestra was supposed to be in these scenes out in the middle of an ocean in a lifeboat away from everywhere. The composer asked the director, "Where are the cameras?")
Anyhow, look no further than film or television comedy for non-diagetic sounds. We don't suppose the "Waa waaa" trombone is actually in the scene! (At least not mostly -- there are a number of classic comic moment when what was assumed to be non-diagetic turns out to be quite "real" -- at least to within the fluid reality of a comedy.)
So you conceive of sounds that reinforce the action or the emotion but aren't pretending to be the actual sounds of some actual thing on stage. But even when the sounds are natural to the environment being presented, I have been tending in many of my recent designs to present them as part of the total mix going out the speakers. Instead of sending an effect to stage speakers and pretending there is a pirate ship on stage, I send to the mains along with the orchestra and pretend we are watching a show that is presenting the idea of a pirate ship.
Sounds subtle, I know!
Wednesday, July 24, 2013
How Do You Do....
I'm entering a new round of teaching and I'm really asking myself what are the skills necessary to create the kinds of electronic gadgets I've been creating.
From my perspective, a lot of it is boilerplate; parts and circuits I already know and can plug in to a new project. I have intentionally kept this collection of known elements small and controllable -- even as each new project I undertake intentionally includes learning and adding at least one new element to the set.
Another large part is the analytic method. Iterative design, modular construction, testing and empiricism and, as I am able to do it, quantification and calculation.
The hardest part to teach is that kind of instinct you get when you have done similar stuff for a while. When you understand not the specific wiring of a part, but the way that wiring is similar to a host of other parts. Like knowing that basically all 8-pin dips will want ground and vcc, and they will often be found on corners of the chip. Like having a sense for the current rating of a part from how physically beefy it is.
And, yes, a large part of it these days is looking for help online. Whatever circuit I'm tinkering with, the chances are good someone else has done something similar. The trick there is being able to sort signal from noise. To know where to look, to be able to navigate in those places where the information might be, and to be able to rate the trustworthiness of what you find. And that also seems to be something that just requires familiarity; time and exposure and experience.
The analytic method seems the easiest to explain. Being able to apply it may be another matter entirely!
When I set out to put lights on the WIZ's costume, the first part of the design cycle was working out just what kinds of light.
When I got a little further on I reached a point of calculation; where I knew the wattage of the various things I meant to use, and I could check that against the known capacity of batteries and see if it was actually possible to put that much light on a costume.
But to get there involved a healthy dose of empiricism. I hooked up lights. I carried them out to the stage, and set them down on a chair, and went out into the audience and looked at them. I did this over and over, with "Pirahna" LED's, 3W "Cree" LED's, light pipe, EL wire, lasers, and a few other things besides.
What I was gathering was empirical but quantifiable data; a sense of just how bright each part was, that I could then use to understand how their numerical data (aka wattage, lumens, field of view, etc.) related to actual visibility in stage lighting conditions.
This particular project had a short terminal cycle; from purchasing the intended parts to opening night was a mere week. I used that time to construct the other circuitry, and make sure I could control an LED strip from an Arduino, but there was no time otherwise to properly iterate and test each element.
The best I could do was to test each section of lighting on the costume before I soldered the final wires.
And although I was able to do a full plugs-out test, the final shake-down under show conditions -- costume on an actor, stage lights on, wireless microphones in use, etc -- was done for the first time in front of an audience.
So the very first part of a project is trying to parameterize what it will take to achieve what you want to achieve.
Say that you are trying to make, as a for-instance, a pair of nekomimi ears.
The two big questions during the first phase of development are then, obviously; 1) what do we need to wiggle the ears, and; 2) how do we control them.
At some point you need to proof the concept. Put a servo on an ear on a wig block and see if it moves as smoothly and swiftly as you intend. Hook up a sensor and see if it is sending you data you can parse usefully.
But before that you need to grok just what kind of servo and sensor is necessary. And for this, calculation (and research) helps.
But we're not talking actual engineering calculation (although I've done that in the past). I'm talking about the simpler tools science uses; order of magnitude calculations, and dimensional analysis.
Order of magnitude is the justly-famous "Spherical Cow" family of approximations. Instead of trying to plug in exact numbers to ten significant digits, you are seeing if you are in the same ballpark or not.
Assume cat ears. Assume they are made out of fake fur and foam. Assume we can make a fairly smooth pivot for them; so as an approximation, the turning resistance due to mechanical friction will be on the same order of magnitude or less than the torque of moving the ear itself.
Borrowing a page from dimensional analysis, I look up a standard small hobby servomotor and see the torque is rated in ounce/inches. So to find out if a small servo will work, I need to be able to plug ounces and inches into a calculation.
A brief look online and I find the shipping weight on a pair of crew socks is 2.4 oz. Assuming the foam and fur is a bit heavier than that (but around the same dimensions) I'd go 10 oz at the outside. Holding up a hand, I'd say the ears are maybe 5" at the base -- that gives a radius of under three inches. So the torque to move them would be < 30 oz/inch.
A micro-servo at Adafruit is listed with a stall torque of 25 oz/inch at 4.8 volts. Which, given my generous assumptions above, is probably enough.
So now let's calculate velocity. I said "twitch" to myself and twitched my own ears (I am one of the small percentage of people who can do that). Felt like a bit under 1/2 second. Assume I want to move the ears from neutral to forward in 1/2 second, that's at least 90 degrees. So as an approximation, I need to be able to move 180 degrees in 1 second or less.
That same servo lists at .1 second/60 degrees, which is a magnitude faster than I need. Of course that's probably no-load speed, but again this seems plausible.
Now, if the speed had been too low, I might have to put in a gear train. Which would multiply the torque by the same factor, plus double it to account for mechanical losses. Had the torque been too low, same idea; put in a lever arm, and reduce the effective velocity.
The thing of it is, to do this kind of approximation -- Orders of Magnitude and/or Dimensional Analysis -- you have to have a sense for what matters and what doesn't. You notice I didn't bother actually including mechanical losses. That is because my experience for machines like this is that torque trumps any losses in the pivot. But the fact that I brought it up; again, experience that even a simple rod linkage will waste significant energy which has to be accounted for in the design.
And that's the tough part to teach, again. You have to do this kind of approximation, and do it over and over again, and hold it up against the real world with empirical tests and research (to see if other people have used a small hobby servo on a pair of cat ears -- and, yes, they have. Which is good enough to proof that this is a method that can work, all else being equal).
And it also required I understood the concept of torque, of angular momentum, of how this is characterized (as mass over a lever arm aka radius.)
And this is physics. Or other sciences. Which means that often what is happening is not intuitive. Your instinct might be, for instance, that a blue christmas tree light of 5 watts is brighter than a blue LED at 1 watt. And it would be, except that an incandescent lamp puts out a broad spectrum, which is then filtered down to just the blue by a coating on the bulb, with the rest wasted as heat. So more of that power becomes blue light in the LED.
Which seems to require you have a basic grounding in whatever sciences may be appropriate. Or at least some basic general science.
And then there's the familiarity with the tools.
I've been using servos for a while. I am familiar with several things about them; that they make noise when they move. That they move at a preset rate. That you need to supply a specific kind of control signal to them (PWM -- pulse-width modulation). That they require the same 5v as much of your electronics, but more amperage than a typical Arduino will supply.
In the case of the WIZ costume, my known tools were Power Darlingtons, Arduino, XBee modules, and my home-brew Blink code. I'd already hooked many of these modules to each other in different projects; PWM dimming of a high-power LED via a power darlington, speaking to an Arduino with an XBee, and so forth. So the interactions were mostly known.
What I did NOT know is if the circuitry -- micro-computer and micro-power serial data link -- would survive in an environment where I was switching several amps of LED on and off. Or if the whole mess would make radio noise and interfere with the wireless microphones.
Now I know. And I know simpler ways to build the next similar device, too. Iteration and empiricism aren't just useful for the project at hand; they are also how you refine the tools you then have available for the next project.
But this makes my teaching project difficult. I can communicate a set of tools, but the skills to know when these tools are appropriate and the range in which they will work -- that is more difficult.
From my perspective, a lot of it is boilerplate; parts and circuits I already know and can plug in to a new project. I have intentionally kept this collection of known elements small and controllable -- even as each new project I undertake intentionally includes learning and adding at least one new element to the set.
Another large part is the analytic method. Iterative design, modular construction, testing and empiricism and, as I am able to do it, quantification and calculation.
The hardest part to teach is that kind of instinct you get when you have done similar stuff for a while. When you understand not the specific wiring of a part, but the way that wiring is similar to a host of other parts. Like knowing that basically all 8-pin dips will want ground and vcc, and they will often be found on corners of the chip. Like having a sense for the current rating of a part from how physically beefy it is.
And, yes, a large part of it these days is looking for help online. Whatever circuit I'm tinkering with, the chances are good someone else has done something similar. The trick there is being able to sort signal from noise. To know where to look, to be able to navigate in those places where the information might be, and to be able to rate the trustworthiness of what you find. And that also seems to be something that just requires familiarity; time and exposure and experience.
The analytic method seems the easiest to explain. Being able to apply it may be another matter entirely!
When I got a little further on I reached a point of calculation; where I knew the wattage of the various things I meant to use, and I could check that against the known capacity of batteries and see if it was actually possible to put that much light on a costume.
What I was gathering was empirical but quantifiable data; a sense of just how bright each part was, that I could then use to understand how their numerical data (aka wattage, lumens, field of view, etc.) related to actual visibility in stage lighting conditions.
The best I could do was to test each section of lighting on the costume before I soldered the final wires.
And although I was able to do a full plugs-out test, the final shake-down under show conditions -- costume on an actor, stage lights on, wireless microphones in use, etc -- was done for the first time in front of an audience.
So the very first part of a project is trying to parameterize what it will take to achieve what you want to achieve.
Say that you are trying to make, as a for-instance, a pair of nekomimi ears.
The two big questions during the first phase of development are then, obviously; 1) what do we need to wiggle the ears, and; 2) how do we control them.
At some point you need to proof the concept. Put a servo on an ear on a wig block and see if it moves as smoothly and swiftly as you intend. Hook up a sensor and see if it is sending you data you can parse usefully.
But before that you need to grok just what kind of servo and sensor is necessary. And for this, calculation (and research) helps.
But we're not talking actual engineering calculation (although I've done that in the past). I'm talking about the simpler tools science uses; order of magnitude calculations, and dimensional analysis.
Order of magnitude is the justly-famous "Spherical Cow" family of approximations. Instead of trying to plug in exact numbers to ten significant digits, you are seeing if you are in the same ballpark or not.
Assume cat ears. Assume they are made out of fake fur and foam. Assume we can make a fairly smooth pivot for them; so as an approximation, the turning resistance due to mechanical friction will be on the same order of magnitude or less than the torque of moving the ear itself.
Borrowing a page from dimensional analysis, I look up a standard small hobby servomotor and see the torque is rated in ounce/inches. So to find out if a small servo will work, I need to be able to plug ounces and inches into a calculation.
A brief look online and I find the shipping weight on a pair of crew socks is 2.4 oz. Assuming the foam and fur is a bit heavier than that (but around the same dimensions) I'd go 10 oz at the outside. Holding up a hand, I'd say the ears are maybe 5" at the base -- that gives a radius of under three inches. So the torque to move them would be < 30 oz/inch.
A micro-servo at Adafruit is listed with a stall torque of 25 oz/inch at 4.8 volts. Which, given my generous assumptions above, is probably enough.
So now let's calculate velocity. I said "twitch" to myself and twitched my own ears (I am one of the small percentage of people who can do that). Felt like a bit under 1/2 second. Assume I want to move the ears from neutral to forward in 1/2 second, that's at least 90 degrees. So as an approximation, I need to be able to move 180 degrees in 1 second or less.
That same servo lists at .1 second/60 degrees, which is a magnitude faster than I need. Of course that's probably no-load speed, but again this seems plausible.
Now, if the speed had been too low, I might have to put in a gear train. Which would multiply the torque by the same factor, plus double it to account for mechanical losses. Had the torque been too low, same idea; put in a lever arm, and reduce the effective velocity.
The thing of it is, to do this kind of approximation -- Orders of Magnitude and/or Dimensional Analysis -- you have to have a sense for what matters and what doesn't. You notice I didn't bother actually including mechanical losses. That is because my experience for machines like this is that torque trumps any losses in the pivot. But the fact that I brought it up; again, experience that even a simple rod linkage will waste significant energy which has to be accounted for in the design.
And that's the tough part to teach, again. You have to do this kind of approximation, and do it over and over again, and hold it up against the real world with empirical tests and research (to see if other people have used a small hobby servo on a pair of cat ears -- and, yes, they have. Which is good enough to proof that this is a method that can work, all else being equal).
And it also required I understood the concept of torque, of angular momentum, of how this is characterized (as mass over a lever arm aka radius.)
And this is physics. Or other sciences. Which means that often what is happening is not intuitive. Your instinct might be, for instance, that a blue christmas tree light of 5 watts is brighter than a blue LED at 1 watt. And it would be, except that an incandescent lamp puts out a broad spectrum, which is then filtered down to just the blue by a coating on the bulb, with the rest wasted as heat. So more of that power becomes blue light in the LED.
Which seems to require you have a basic grounding in whatever sciences may be appropriate. Or at least some basic general science.
And then there's the familiarity with the tools.
I've been using servos for a while. I am familiar with several things about them; that they make noise when they move. That they move at a preset rate. That you need to supply a specific kind of control signal to them (PWM -- pulse-width modulation). That they require the same 5v as much of your electronics, but more amperage than a typical Arduino will supply.
In the case of the WIZ costume, my known tools were Power Darlingtons, Arduino, XBee modules, and my home-brew Blink code. I'd already hooked many of these modules to each other in different projects; PWM dimming of a high-power LED via a power darlington, speaking to an Arduino with an XBee, and so forth. So the interactions were mostly known.
What I did NOT know is if the circuitry -- micro-computer and micro-power serial data link -- would survive in an environment where I was switching several amps of LED on and off. Or if the whole mess would make radio noise and interfere with the wireless microphones.
Now I know. And I know simpler ways to build the next similar device, too. Iteration and empiricism aren't just useful for the project at hand; they are also how you refine the tools you then have available for the next project.
But this makes my teaching project difficult. I can communicate a set of tools, but the skills to know when these tools are appropriate and the range in which they will work -- that is more difficult.
Tuesday, July 16, 2013
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).
-- 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;
Processing spits out a serial word to a SparkFun USB adapter holding a Series 1 XBee Pro.
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.
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).
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).
Wednesday, July 10, 2013
Wizard Report I
It works.
We're in tech, opening this weekend, so I can't spare much time for detail.
The eponymous "Wiz" is wearing a coat with RGB LED strips along the lapels and 3W RGB's in the shoulders, feeding into a small festoon of cut-end light pipe.
Because of lack of development time and budget, his controller is an Arduino, with a Seeed Studio XBee shield attached. To allow the micro to control the 2-3 amps of up to 12 volts required by the various lights, there is a separate driver board.
CPU, driver board, and an 8-pack of AA rechargeables are each in their own pocket sewn into the back of a vest he wears under the coat. It worked. He was able to move, the lights looked good (and bright!) and we could control them from the back of the theater.
Here's the only detail I have time for today; a little "what are the differences between these pictures?" exercise.
Driver board being built:
Driver board in finished form:
Well, besides the Altoid's tin, there are a few subtler (but very important!) changes.
The high side of the constant-current power drivers are now on an independent bus, instead of being tied to the positive lead of the main power supply. (That gap in the board was to put a 12v DC-DC converter for the 12V LED strips. Or I could have tapped the battery twice to put 9V across the constant-current drivers. But in the end I went with simple; a 12V system bus).
And there's an even subtler fix:
The lads and lassies in Singapore assembled one of the constant-current drivers incorrectly. I didn't realize this until after I'd blown out the red channel on one of my Cree.
Incidentally, some people recommend removing the diode rectifier array completely; they claim it causes RF noise. I haven't had a problem with the circuit yet.
And that is actually the most important part of this. Despite the Wiz's microphone being patched into a driver circuit for nearly ten meters of LED strip, and the poor actor being draped with high-amperage PWM circuitry, the Sennheiser wireless body pack has performed without issue or extra noise.
We're in tech, opening this weekend, so I can't spare much time for detail.
The eponymous "Wiz" is wearing a coat with RGB LED strips along the lapels and 3W RGB's in the shoulders, feeding into a small festoon of cut-end light pipe.
Because of lack of development time and budget, his controller is an Arduino, with a Seeed Studio XBee shield attached. To allow the micro to control the 2-3 amps of up to 12 volts required by the various lights, there is a separate driver board.
CPU, driver board, and an 8-pack of AA rechargeables are each in their own pocket sewn into the back of a vest he wears under the coat. It worked. He was able to move, the lights looked good (and bright!) and we could control them from the back of the theater.
Here's the only detail I have time for today; a little "what are the differences between these pictures?" exercise.
Driver board being built:
Driver board in finished form:
Well, besides the Altoid's tin, there are a few subtler (but very important!) changes.
The high side of the constant-current power drivers are now on an independent bus, instead of being tied to the positive lead of the main power supply. (That gap in the board was to put a 12v DC-DC converter for the 12V LED strips. Or I could have tapped the battery twice to put 9V across the constant-current drivers. But in the end I went with simple; a 12V system bus).
And there's an even subtler fix:
The lads and lassies in Singapore assembled one of the constant-current drivers incorrectly. I didn't realize this until after I'd blown out the red channel on one of my Cree.
Incidentally, some people recommend removing the diode rectifier array completely; they claim it causes RF noise. I haven't had a problem with the circuit yet.
And that is actually the most important part of this. Despite the Wiz's microphone being patched into a driver circuit for nearly ten meters of LED strip, and the poor actor being draped with high-amperage PWM circuitry, the Sennheiser wireless body pack has performed without issue or extra noise.
Subscribe to:
Posts (Atom)