TTATC temple tech breakdown
On the decisions made for a small bit of code for the temple at a regional burn…
Temples are decidedly low-tech affairs usually and this one was no exception except for the hanging chandelier — trick with the chandelier is that we wanted it to appear very organic and respond to its environment, to not only be part of the same wood and fabric world of the temple, soft and natural and muted, but also set the tone for it from afar.
In my experience it is very easy to make LEDs look cool, but it is very hard to make them feel organic and analog. Even slow fades sometimes somehow feel digital. More like the RGB numbers changing behind the scenes like clockwork rather than a river ebbing and flowing.
First job was to figure out what to use. We didn’t want any wires, so some sort of central computer was out, and I hate soldering and am terrible at it so I kinda wanted not to do that. Luckily adafruit makes a little arduino board called the circuit playground express that not only has 10 LEDs, it also has a temperature sensor, and IR sensor, an IR transmitter, an accelerometer, some buttons, a switch, a microphone, and a speaker. For like $20. With having 8 balls, and also needing a large-ish battery for each one (no one wants to take the whole thing down and recharge 8 batteries) that meant the light was def the most expensive part of the whole project, but not terrible.
We knew we wanted purely organic diffusion, so Alina ended up using some cheap grapevine balls from the internet and then weaving in the fabric from the Oracle last year, which looked great and totally worked and had the symbolism too.
At first we wanted the balls to be warm white, but with the theme we decided to make them more green. But green can be a weird color and kinda harsh in its extremes, so I tempered it towards green-blues always for a warmer and watery effect. For the curious, in terms of RGB (1–255) values greens were almost always between 50–200, blues between 10–75, and reds between 0–50. There were times when randomness shifted the balls towards yellowy-brassy greens because the red crossing over the blue, but they were meant to be much fewer.
Randomness! For organic things randomness is always first and foremost because nature always has noise in its patterns. People will find patterns in pure randomness, so you can put a ton in and still hold your theme. So there was a ton of randomness there in terms of how fast any ball was changing colors at any moment and where it was moving to.
Change! I wanted the lights to change but also appear static. Sort of a watched pot never boils effect. If you are looking at the lights they might appear to be subtly shifting (or not) but if you look at them 5 minutes later, they might all be totally different. Mostly this was a function of shifting colors slowly, but also at different times (hence randomness).
Interaction! We wanted the lights to respond to the environment, but in pretty subtle ways. So they were sound reactive (they brightened) if you were near them and singing or ringing a bell (they listened mostly for changes in the treble range), but I didn’t ever want them to pulse with the bass of a soundcamp, so they couldn’t be so sensitive to spikes of sound, especially bass.
Movement however, they were quite reactive to. If they were shifted off their current XYZ axis, green tones would scale way down and red tones would scale way up in logarithmic proportion to the value of the change which usually meant a shift towards purple. This didn’t happen much without physical interaction, or a heavy wind, breezes wouldn’t do it, but it was a cool easter egg if you found it. We didn’t want a ball to stay stuck purple if it somehow moved permanently, so it also continually recalculated it’s “home position” as the average of its last 100 position readings.
Also reactive to temperature (warmer colors with warmer temps) but not really noticeable since off during day.
Smoothing! All this and any change still felt digital, so I decided to add a sort of drag-delay factor. At any given time a light would be an average of its last X color readings, where X was random. This meant that if you fed it a large change (getting brighter with sound, or changing color with movement) you would still see an immediate shift because the new reading would be extreme enough to shift the average, but the weighting factor of having a random amount of readings would mean that the balls tend to pull towards or away from any given state rather than just shifting to it immediately (and also basically fixed the pulsing with bass problem because 1 or 2 sound readings generally not enough to shift the average that much.
Coolest effect was that if you hit the balls you’d see the ball you hit immediately move towards purple and then see the purple bounce around the lights as each ball hit another one.
In terms of adjusting on the spot, you could adjust the brightness and levels of movement and sound sensitivity on the spot by using the switch and buttons on the board. We ended up turning up the sensitivity on most of the balls. Also you could turn them off during the day but it required like 10 clicks and in retrospect it should have somehow been able to be done with a remote with the IR reader somehow. But whatever, still better than having to rip out those batteries and recharge them.
Arduinos are great cause they kinda always work, only run one program, and run it automatically. We put them in ziplock bags for the rain and they all still work, no idea what water would have done to them, but humidity and being sealed in plastic didn’t seem to bother them. a 2500 mAmp battery seemed to run them for about 24–30 hours, which is about what we needed for sunset to sunrise for two nights.
That being said there was still one light that was kinda perma-glitched and always shifted towards red or white and I have no idea why. Code should have kinda worked or not worked, not worked differently for one ball, but that’s programming for ya and it actually made it look better, so that’s also programming for ya.
Programmed in a mess of spaghetti code in circuit python, cause I don’t really know python, but still better than arduino code. Circuit python def a bit slower, but not a big deal for this project. Used the fancyled library which is a port from the fastLED library for arduino. Will try to get it on github.
And that’s the thoughts that went into making some green and blue balls hanging in the air. It’s actually my favorite “art thing” I’ve ever coded cause it somehow really did get towards the analog side of the analog-digital spectrum.