for the past couple of months i've been working on a project called "schhplttlr: electric beats" with daniel kluge and eugen kern-emden presented by peer to space and in collaboration with the department of cultural affairs munich.

the premise
Using movements inspired from “schuhplattler” (traditional Bavarian folk dance). The dancers generate beats and light via sensors. Musicians, media artists, dancers and choreographers experiment with these movements during a three-day long interdisciplinary workshop, in which the audience may freely participate. The results were performed at the opening evening on July 15, 2010.

this documentary film and selected photographs will be projected in MaximiliansForum, munich from 19 july 2010 until 5 september 2010.

the process (slightly abridged)
we began this project at the beginning of may, wanting to create something that could only happen in munich but also connect our collective interests of music, physical computing, performance, textile electronics, etc. we stumbled upon the idea of schuhplattler but we weren't sure yet how to represent it. literally? artsy-fartsy? projected (generative) images? physically? schuhplattler is a dance of courtship. it all started coming together, female and male. light bulbs flitting like fireflies in the spring, feminine, and harmonic. fluorescent lights structural, rhythm, and manly.

there were three main tools we used, max/msp for receiving and processing signals from the sensors and controlling the sounds. these signals were then sent out as open sound control (osc) messages to processing. which converted the messages into a signal for arduino which via relays turnd the lights (incandescent bulbs and fluorescent tubes) on and off.

we began prototyping. daniel focused on sensor creation and sound control. the gloves and other sensors were made using conductive foam. the wearer of the sensor presses the foam to complete the circuit. these values were then fed into max/msp where daniel weaved his magic, triggering sounds and controlling sample. eugen focused on programming reactive projected graphics (later abandoned). my task was to simply turn on light bulbs with arduino using processing.

by the time july rolled around we had successfully built a small prototype. eight light bulbs divided into two groups, four fluorescent bulbs, with working glove and thigh sensors. one small hurdle we had yet to solve 100% was the communication between max/msp and processing. as i said before we chose to osc as the communication medium using the oscp5 library. this was fine, however the way one builds a proper osc message in max/msp is (still) elusive to us. in the end we just put all of the necessary info within the message (control) field. on top of that when we did send messages there was a slight delay. we solved the delay by connecting both of our computers directly with an ethernet cable. we determined the delay was because we were connected via wifi.

we had still yet to test with the dancers or even move into the space, none of this happened until the week of the performance. as you can see MaximiliansForum is big and empty. but now we at least knew how everything would be connected it was now just a matter of taking the prototype and multiplying everything to the final quantities.

you can see more videos of our process at

the hardware
we kept things fairly simple on the hardware side to control all of the lights. we used a single arduino duemilanove and 12 modules built of the following parts.

2N3904 transistor
100V 1A 1N4002 diode
G6B–1114 5VDC relay
10A Fuse* (didn't actually implement the fuse)

as usual i have to thank my pops for his help with the electronic stuff. initially i soldered all of the components as the relays were jumping out of the breadboard sockets, because of the fast switching i assume. however, this proved disastrous and in the midnight hour i de-soldered everything and used breadboards instead.

as for the software on the arduino, one thing that had perplexed me was how to send an array of data to the arduino from processing. for the initial prototyping i was simply sending (per light group) a character for "on" (i.e. "Q") and then sending another character for "off" (i.e. "Z"), multiply this by 12 and you can see how ridiculous it is. i needed something that wasn't based on arbitrary key characters.

since arduino is it's own little computer it's internal timing isn't in sync with the signal sending computer (my macbook), this is why you have to use a starter marker. arduino waits for the maker buff[0] =; and as soon as it sees it, i can then tell arduino that everything following the marker is what it needs to use. i fill the rest of the buffer with these values for(int i=1; i<13; i++) buff[i] =; in this case, 12 integers "0" or "1" which tell the output to be on or off.

here's a simple example of the arduino code we used to control the lights.

int PIN_LICHT[3] = { 2,3,4 };

//buffer should be long enough to hold the desired values
//as well as the starter marker
//i.e. L000
byte buff[4];

void setup() {
for(int i=0; i<3; i++) pinMode(PIN_LICHT[i], OUTPUT);

void loop() {
while( Serial.available() >= 4 ) {
switch( byte( ) {

case 'L': //starter marker
buff[0] =;
for(int i=1; i<4; i++) buff[i] =;


for(int i=0; i<4; i++) {
if(buff[i] == 0) digitalWrite( PIN_LICHT[i], LOW );
else if(buff[i] == 1) digitalWrite( PIN_LICHT[i], HIGH );


the software
the light bulbs were controlled by rosanna's glove, each finger could control different pre-programmed patterns. the patterns controlled

to make the bulbs flicker on and off as desired was a bit complicated. we had originally thought that each finger could control a group but this proved to be rather boring. so eugen programmed a rather ingenious pattern system. the patterns controlled just how much "color" (i.e. groupings of bulbs) could be on. this allowed us to control the build up of the performance. these patterns could be cycled through by the glove.

the fluorescent lights were much easier to control one hit equals one light, regardless of which dancer sends the signal. the only exception was one of the dancers had a sensor on his shoe, when this was activated all of the fluorescents came on at once.

we created an override feature for all of the lights incase during the performance we needed/wanted to turn certain groupings off

the night of the performance went well, there's one glitch that still bothers me. the relays for the fluorescent lights will sometimes not switch off, keeping that group of fluorescents on. eugen and i tried for hours to solve the problem going one by one and replacing wires, relays, etc. i still have no idea what the problem could be. the only solution we found was to pop out the offending relay and put it back in. i had to do this once during the perfomance. reception and feedback has been great. this was a great project and we all learned a lot from it.

in the near future i will post the code (processing and arduino) we used from the event. so i've started a google project for the source in the meantime if you're interested in the code just send me an email.

also throughout the project we continually updated my processing interface very soon i will update the archive on the google code page to reflect these changes which will include Timer and MultiTimer functions.

Labels: ,