And yet again, an application comes along that if I had the gadget, I would use it.
That's been part of the problem. I try to brainstorm what shape the circuit should be to be a flexible general-purpose FX tool for theater. But I have trouble dreaming up the actual applications. Until a show comes along -- like the light-up coat for the WIZ, or an on-stage miner's lamp -- and I realize what I wanted to have had available.
The application that got dropped on me yesterday is to have a light inside a locker that pulses Dalek-style with the voice of the actor. Now, I have one already:
Which works, more-or-less, and will do this show (this has a 741 pre-amp, which is bypassed, a 386 power amp which is pretty much a waste of space in this design, and an ATtiny45 programmed off-line via the Arduino IDE. Under the heat sink is a power Darlington; it takes audio input on one end, and can control 50 feet of LED strip light at 12 volts at the other).
Using this of course requires running power out to the light itself. Or you could run the lights with a battery but the audio would still be on a wire.
The PLS (to borrow Tomb Raider terminology) is designed from the get-go to be portable, and battery powered. And to have a remote link.
But where this gets interesting is in processing audio. Upon reflection, the neatest way to do this may be to treat audio as just another input stream on the host computer of the controller node.
So the topology works this way; a Processing ap written to take an input of Core Audio, and spit serial commands out to an XBee node. On the remote end (the light-up locket, in this application), the serial data stream through the second XBee node sends real-time adjustments to the desired output, and the AVR runs the PWM serving the light.
(One thing I've been freezing on is sometimes I want a general high-power switch, such as a trio of Power Darlingtons: and other times I want three constant-current drivers matched to a specific compact LED.)
(Or maybe four; a lot of lighting effects look better with a RGBA instead of RGB. Especially anything that is trying to simulate light heavy in the ambers; firelight, candles, oil lamps, etc.)
(Because while I dream of Green Lanterns, two recent applications I might have served with this both required a different form factor. The WIZ coat had light-up lapels, and the stage had almost fifty feet of the same LED strips).
The other thing I'm realizing with this is that rolling custom software is probably going to be necessary in most of the applications that pop up. I can easily see needing to process audio, for instance, but doing a Fast Fourier transform on it so frequency is the driver, not amplitude. I also noticed during The Wiz that having a DMX512 option would be extremely helpful!
Most of which is host-side, but then there's applications like Crystal Ball or Blaster where the data (actor's movements, sensors, controls) are at the end node, and it adds an unnecessary level of complexity to have to send all that sensor data back to a host computer where it gets interpreted.
Oh, yeah, and unless your theater employs a Hollywood Hacker, no-one is going to write raw code on an ad-hoc, application-by-application basis. Which means that even if there's a central coordinator running on a laptop, taking MIDI from the pit or button-presses from a Stage Manager or sensor data from the stage, and sending it out to remote nodes that light up or throw relays and solenoids, there needs to be a complete, robust, and extensible software framework.
Which is as much beyond my current software skills as engineering a proper set of constant-current drivers with PWM is beyond my electronics skills.
No comments:
Post a Comment