This is part two of a series of blog entries for the massive percentage of the myriad ALG fans who are fascinated by the technical intricacies of all the AustinLightGuy Light Suits. If you’re in the small majority of people who have no interest in how to pull off a mobile, illuminated, Christmas light suit with various light accoutrements, you might not find this all that interesting. Surely, though, there aren’t many people out there who don’t want to assemble mobile light-emitting apparel, so this year I’m documenting my endeavors here.
In my last entry, I described some problems I had getting sound from a laptop to work over Bluetooth speakers (which I plan to mount in an illuminated Light Staff). The speakers will broadcast sound – primarily Christmas music – with which the lights are coordinated. Although it took some fiddling, getting the Bluetooth speakers working was really just an annoying detour. The much more significant effort has been the development of software that drives lights in a sequence. More recently, my effort has been in developing software that plays mp3 music coordinated with light sequences.
Initially, my light sequencing efforts were focused solely on my house. I guess it was back in the early aughts (’00 or ’01) when that awesome video of that dude’s house, synchronized to music from Transsiberian Orchestra, made the circuit on the internet. At the time, that seemed unachievable – he was using equipment and software that was mainly only accessible to professional lighting people. Back then I was already festooning my house with a disproportionate number of lights. While trying to pull off a light show like his wasn’t a challenge I wanted to take on, the more I thought about it, the more I thought I might be able to do something a little less ambitious. I wound up using AR-16TM relay controller cards from EECI and building my own software-driven relay control box for driving my home lights with pre-designed patterns. Back then coordination with music was really on the radar. I’ll go into more detail in my next posting on that hardware, but also the newer generation of stuff I’m using in the light suits.
Back then, I needed software that would let me lay out light sequences, that is to say,
sequences of of on/off patterns that would be interesting. I decided the best bet was probably to develop a Windows-based graphical program that would display relays as a set of horizontal spans on which I could drag-and-drop widgets represent “on” timespans that could be moved, stretched or shrunk, etc. (see screenshot), and which would then play back those sequences, generating on/off signals sent via serial port, as the sequence progressed. I wound up writing a custom program in C# to do this, which I called EverSequence. I’ve continued to enhance that program over the years, adding support for X10 and Insteon controllers and a simpler relay card from Pencom Design, improving usability, etc.
Eventually, I did get to the point where I didn’t have much more to do with it, so back in…I think it was 2008…I got around to adding synchronized sound. It actually took a couple of years – I only work on this stuff around the holidays and adding sound complicated things a bit. Until then, the sequences weren’t really time-accurate. The main program was basically driven by one timer that fired every 10 milliseconds. When it fired, the code looped over all the relay bars, and if an on or off was due, would flip the designated relay, then the timer would start again. But if there were a lot of relay timer spans (and there are a LOT), it could get behind. A span that was at, say, 10 seconds into the sequence, might fire at 10.1 seconds. That’s a big problem if you want them timed to an mp3, which always plays at an accurate speed.
So for Christmas 2007 I wound up re-writing all that to use a timer for each relay channel, or bar, instead. When a sequence starts, the code through all the channels, looking forward to see when the next event (relay on/off, pause, loop, etc) is due for that channel, and sets a timer to fire at exactly that time. When it fires, the associated event is triggered, then it looks forward in time to when the next is due, sets the timer for exactly that amount of time, and restarts it.
Since I don’t work on this stuff full time (AustinLightWife might argue otherwise :-), it took one season of refactoring and debugging to make this change, but once I worked the bugs out, it worked great! After that, it was relatively simple to add a new span type that played an MP3 or WAV file – the Windows Media SDK makes that quite easy in C#. Now, you’ll see lights synchronized to Transsiberian most nights around Christmas. I broadcast the music by hooking a low-power FM transmitter, meant for MP3 players, up to the audio-out on my PC (so as not to annoy the neighbors), so bring your car or FM walkman 🙂 By the way, you can download the latest sequencer program, which I call EverSequence, from here.
Oh yeah, I almost forgot…at one point, I decided I wanted to let people get on my website and control my lights. I also wanted to be able to queue multiple sequences in a row and have them play automatically a certain intervals with a SequenceTimer. To accommodate both, I used .Net’s sweet remoting capability. I isolated all the classes related to defining a sequence in there own assembly and made the Sequences serializable. Then I made a SequenceCoordinator that is essentially a remotable queue. Clients (the website or the SequenceTimer) invoke enqueue() remotely to add Sequences. I then enhanced EverSequence to include a “slave mode”. In slave mode, the sequencer also checks the SequenceCoordinator via remoting, but looks to see if there is any Sequences in the queue and, if there is, dequeue()’s it and plays it.
Well, this recap of past efforts has wound up longer than I thought, so check back for Part 3, where I’ll actually talk about this season’s software efforts.