Yeesh.  A really short day in the LEMUR studio this evening.  Leif helped me out with note dampening on the guitar bot which helps with things like this:

VIDEO!

More to come tomorrow. The long haul for show prep (which happens on Friday, May 2nd) will be over this weekend. All my performance is belong to you.

Okay day three.  I had a vision in the shower.  That’s usually how it happens.  Change of plans somewhat.  Today I shifted focus from gestural mapping cueing to programming.  The “ModBots” / or the bots that are mainly percussive and tend to hang from the ceiling at LEMURplex / are easy enough to control using simple thresholding detection while wearing the TwitchSet.  But the bots with notes, i.e. the XyloBot and the GtrBot are much harder for me to control with any sort of fine resolution.  The GtrBot, for example, takes MIDI notes of 36-81, which means 45 note resolution.  I had been trying to control notes variations using one axis of the TriAx accelerometers on the TwitchSet.  An accelerometer is not a tilt switch and is a bad substitute for one in this case of trying to get 45 steps of resolution with a 180˚ rotation of my shaky hand.

Besides, I’m not a musician.  I’m not going to become a musician just because I have the pleasure of spending the next two weeks with musical robots.  I’ve decided to focus on the performative aspect of why I’m doing the residency.  Hell yes.  I think I’ve got something going here.  Below is a short clip documenting the partial results of today’s programming.  I didn’t write the song.  And I’m not going to tell you what song it is based on, or who wrote it.  That’s the surprise for the performance.  In progress:

Recently I spent my first significant amount of time at LEMURplex in Brooklyn as part of my April residency in preperation for the Resident show on Friday, May 2nd.  I’m not great with Max/MSP for logic, which seems to be the biggest hurdle for me right now.  That and not possessing the ability to write music are bringing me down.  I will not rest though.  Hopefully I’ll use these obstacles to make more interesting work.  Here’s a video of yesterday’s experiments:

April showers bring May flowers musical robots.  I am fortunate enough to be a ReSiDeNt  at LEMURplex this month in Brooklyn.  LEMUR stands for the League of Electronic Musical Urban Robots.  Um….could there be a more perfect residency?  I get to interface with their xylobot, guitarbot, hydrobots, and modbots.  I’m planning on using the Twitchset and Performoshoes (together)as a starting-off point with the bots.  I also plan on doing a lot with the fiddle~ object.  Fellow ITPer and now full time LEMURer, Leif gave me a breif walk-through of the space yesterday.  I’ll be setting up another blog over at LEMUR to document my stuffs.  Here we go…

PONG

This week’s task:
“For this project, the whole class will play a giant game of networked Pong together. You’ll be given the address of a server on which the Pong game will run, and the details of the protocol for each Pong paddle client. Your assignment is to make a physical input device that logs into the server and plays the game.”

idea:

The classic Pong game maps physical movement to a virtual screen representation. How can I magnify and extend this?

mapping the real to the virtual:

The pong controller from the classic game is fairly simple. Rotate the controller counter-clockwise and the virtual paddle moves left, rotate the controller clockwise, the virtual paddle moves to the right. With such a structured and simple set of parameters, mapping the movement became an excercise not in what was most suitable, but what was most fun and expressive.

After some time working through a pong set-up based on some of the techniques of Matthew Barney, I decided to take the thinking in a less lofty direction. What I ended up with, is a very physical mapping scheme: taking off one’s clothing.

implementation:

Using a very low resolution method of analog video tacking, I was able to determine whether the paddle (stripper) was to move left or move right.

A small security camera feeds an upturned black and white monitor. The monitor is capped with a perf boards covered with strategically placed photocells. As the stripper moves from left to right, their corresponding image moves left and right on the monitor. Pixels grow brighter and fade. The photocells pass the corresponding brightness values to an Arduino module, which connects to the network and plays the game. Arduino Code.

Rocio and I (in the absence of Chris Paretti and Kati London) presented our concept of “The Future of the Clock Radio in a Networked World”:

Ultimately we decided to flesh out the “Around the World Clock” from last week’s notes. The clock has now been dubbed “RadiUs.”
We got some good feedback, and Rocio and I both expressed some interest is exploring the project further.

A pdf of the presentation can be found here. Although without the notes we read from it doesn’t really do you much good now does it?

The Future of the Clock Radio in a Networked World :

This week’s project actually spans the next two weeks. Woking in groups, we are come up with a paper project implementation of the alarm clock of tomorrow. I’ve put an order in for a flux capacitor, but it looks like Sparkfun is all out. Here are our groups initial outlined ideas:

All of our project proposals seem to deal with this subject through awareness — alarm as carrier of information rather than closed alert system.

All of our project proposals seem to deal with this subject through awareness — alarm as carrier of information rather than closed alert system.

* BRACELET

WHO:

-wake up with out audio
-doesn’t mind sleeping with bracelet
-doesn’t mind vibration
-needs multiple users (choice or random)

WHAT:

-soft, wearable, networked bracelet and pulse sensor
-internal clock
-temperature sensor
-time display (for confirmation / feedback)
-e-ink?
-buttons?

WHY:

-human to human connection
-non-audio
-warmer
-disappear the device
-social pressure as a mechanism for waking up

HOW:

-flexible pcb
-wireless
-bluetooth
-802.11
-galvanic skin
-peltier junction
-vibrating motor

* AROUND THE WORLD CLOCK

WHO:

-audio heads
-interested in waking to intimate others
-around the world

WHAT:

-international
-networked
-automated
-synched
-couplings
-audio to audio
-1 to 1
-stand alone
-standard alarm clock
-song failsafe

WHY:

-make connections
-social pressure
-unique experience
-mutual interests in waking up
-creative authors

HOW:

-socket connections
-social contract
-ambient modulation
-connection happens

* FUTURE CLOCK

WHO:

-reminds people of externals
-timesavers
-masochists
-egotists

WHAT:

-facts
-programmable
-stories
-taxi cab confessions
-story corps
-pseudo harper’s index relating to the amount of sleep you had

WHY:

-content driven
-juxtaposition of realities
-wake up call
-observe
-update
-connecting with others

HOW:

-subscription
-feed reader
-user specific / tailored content
-text to voice
-automated system able to pull data from anywhere and apply time equation to tailor content and drive text to voice wake-up info

WHAT:

-wireless
-asterisk server
-microphone
-speaker
-voice activated

moonwalkers

For this week’s project we chose from a list of three simple parameters: ACTIONS/THINGS/RESPONSES.

My respective choices:
-dancing
-sneakers
-music

The initial idea involved a pair of old sneakers, repurposed, to dynamically manipulate a sound file.
Basically I wanted to build shoes that would BOOM! when you walked. The louder you stomp the louder the BOOM! In a sense — “giant” shoes.

The two FSR‘s I was working with broke at the eleventh hour, and the trouble-shooting that insued, reinvented the project for me.

The Input:

Using my believe-it-not-only-about-a-year-old Saucony’s, the first step is deciding on the connection between the sensors and the microcontroller. (As a side note, my professor, Tom Igoe has switched to using the Arduino programming interface ove the PIC when teaching this and other physical computing courses). Since the original FSR’s I used were resistors and not potentiometers, I only need two lead wires connecting the sensor to the Arduino board. I know I want to keep the functionality of the shoes intact when not in use as stomping around like a giant (and eventual moonwalking awesomeness), so a detachable connection is a must. I originally thought of using CAT5 cable for it’s low cost, but then I realised i had fifty quarter-inch connectors sitting around from a project that went a different direction. It also compliments the theme of music and dance nicely.

tip: don’t use a drill press to drill through shoes.

I’ve embedded the jacks in the shoes after carefully drilling through the material using a hand drill and a utility knife. The tricky part is making sure the thickness of the sole is enough to entirely embed the jack, and still be able to lay the insole back into the without the jack digging into my heels. I made sure the jacks fit right before I solder up my sensors.

Since my FSR’s kicked the bucket, I’ve decided to use simple photocells – or photo-resistors, since they’ll give me the same analog values that I need. It is amazing how a simple logistics change such as this can change the course of the project so drastically. Now, since I can no longer measure the force of the foot coming down, I am going to have to measure basic distance from the ground, based off the “brightness” values I will get from the photocell. Because of this, I won’t be able to change the volume of the “giant” sounds, so I’ll have to switch to a different mapping of values. Well…what about moonwalking.

The basic assumption is, on a very small scale (about one foot), barring my presence on a light up dance floor, the further my foot is off the ground, the larger the values I will see coming in. This is what will determine whether I am actively moving, which is now what I am looking for over force. Having worked with photocells before in other projects such as Relay1 and Relay2, I feel confident the little variable resistors will work well embedded in the heels of the shoes.

The process is simple enough. I’ve used nails to make a sort of pilot hole in the rubber and then pass the two legs of the photo cell through to the inside of the shoe. I’ve also “counter-sunk” the sensors in the sole so the surface of the photocell doesn’t get damaged by my walk to the disco.

Solder up some leads connecting the photocell to the jacks, make sure I’ve got nothing poking out, slap the insoles back in and my moonwalkers are kickin! now for the fun stuff — how do I control Billy Jean?

The Brain:

I didn’t want to spend too much money on a one week prototype, so the Nestle’s Quick box I found laying around was a literal sweet find. Stylin’ and protective the box proves a durable and cute housing for my Arduino and bread board.

A couple of holes for the 1/4″ jacks and one for the USB out and I’m ready to start programming.

Like I said, I’m in Arduinoland now. Similar to Processing in evvironment and syntax, it’s an easy pick up for a beginner like myself. It doesn’t hurt that I’m only doing an analog in reading.

here’s the code:

#define leftLed 13
#define rightLed 12
int leftShoe = 2; // select the input pin for the shoes
int rightShoe = 3;

void setup() {
pinMode(leftLed, OUTPUT);
pinMode(rightLed, OUTPUT);
Serial.begin(9600);
}

void loop() {
int serialVar1 = analogRead(leftShoe);
int serialVar2 = analogRead(rightShoe);
if(serialVar1 > serialVar2){
Serial.print(serialVar1, BYTE);
}else{
Serial.print(serialVar2, BYTE);
//Serial.print(“\t”);
}

if(serialVar1 > 100){
digitalWrite(leftLed, HIGH);
}else{
digitalWrite(leftLed, LOW);
}

if(serialVar2 > 100){
digitalWrite(rightLed, HIGH);
}else{
digitalWrite(rightLed, LOW);
}
}

easy as pie. This gives me some nice scalable int’s into MAX. It turn out that most people use MIDI to communicate in MAX. Well, it turns out that serial isn’t so bad either. So long as your send the values from the boArduino in BYTE format, you’ve got some happy patches.

It also turns out that Michael was right, Billy Jean is not my lover, and neither, I thought was MAX. For some reasons beyond my control and other well within my control, I was unable to read serial data in to Processing. I was also unable to read serial data into Java…and Isadora. I just want to dance, and these already i’ve exhausted the three programmng languages I have become comfortable authoring in. It’s time to turn to MAX/MSP. As a first time MAX user, I am already somewhat comfortable using the graphical programming environment I’ve grown used to in Isadora. However, the project has a short deadline and I am finding it inefficient to troll through every help page. GabeBC and Chris Kairalla (both somewhat newbies to MAX themselves) came to the rescue with a few examples to help me out. With my new MAX skills I’m able to format the data to give reliable foot action reading and damned if I’m not moonwalking everywhere I go.

The MAX patch basically loads a file (in this case Michael Jackson’s ‘Bad”), then scales the volume and speed relative to the values it sees coming in from the Arduino, and subsequently, the shoes.

The result: hot.

Here’s a screen shot of the simple patch:

The Output:

watch that hot little clip one more time.

Throughout the course of this class, I plan to dedicate “week.n” entries to progress on related projects, thoughts about that week’s readings, and other miscellanea related to the networking of objects.

The four main projects however, as detailed in the syllabus, will all have their own dedicated entries which I will link to from week to week.

That said, our first project is due week.02:

Project 1: Physical Computing Improv