So this was the week to make it all happen. We finalized our design, and decided to lasercut instructions onto the wood we were using for our display. Emily is an Illustrator whiz, and whipped up a great layout. We had it in our heads that we would have an outline of a tape cassette on the wood, which people would then put a tape over. Luckily, we were able to find some vector art on the internet, so it wasn’t too hard to make the tape design. Next, we layed out text describing how people should insert the tape, thread the ribbon around bobbins and across the tapehead.
Test board, still need to tweak it a bit
Another missing piece in the puzzle is that we hadn’t finalized what speakers we were using until this week. We wanted ones that were about 2″ diameter, but still loud, and affordable. We ended up buying these from Amazon. We bought 2, thinking we could split a pair in two and have one left over, but when they arrived it turned out we couldn’t easily divide the power and stereo signal, so we decided to mount one in the front facing outward, and the other in back facing inward and amplifying the sound against the board.
front speaker mounted, the next ready to go
Also, here’s the code we ended up using. It’s pretty simple, just takes the voltage input, and divides by our maximum sensor reading, then multiplies the result by 255. There is a threshold in there so we could adjust for when the signal sends data even when no tape is being run over it.
/* Tape Translations, 2010
by Emily Webster, Genevieve Hoffman and Ju Yun Song
www.tapetranslations.com
*/
float brightness1 =0;
int potPin1 =0;// Analog input pin that the potentiometer is attached to
int inValue =0;// value read from the analog sensor
int outValue =0;// value after averaging
int absInVal =0;// absolute value of inValue - threshold
int threshold =8;// threshold - we ignore values below
float maxValue =200;// maximum value we read from sensor
int led1 =5;
void setup(){// initialize serial communications at 9600 bps:
Serial.begin(9600);// declare the led pin as an output:
pinMode(led1, OUTPUT);}
void loop(){
inValue = analogRead(potPin1);// read the pot value
outValue =((abs(inValue - threshold))/(maxValue - threshold))*255;//float outValue = map(outValue, 0, 30, 0, 255); //check boundsif( outValue >255) outValue =255;if( outValue <11) outValue =0;// don't know if this is the best way to do this
analogWrite(led1, outValue);
Serial.print("inValue = ");
Serial.print(inValue);
Serial.print('\t');
Serial.print("outValue = ");
Serial.println(outValue);
delay(20);// Serial.println();}
emily gluing boards - she's a pro
components all in, almost done!
here are the guts, pre arduino and perf board (goes on the left)
A little note on lightbulbs. We really wanted to incorporate the form of an incandescent light bulb in this project. Like the cassette tape, it has a really wonderful form that I have grown up with, have many memories and connotations of, but I know that people in the future will not necessarily share my sense of familiarity. These technologies are on the way out.
Anyway, we knew that we wanted our media controller to translate sound data into light. We tried to our hands on a 12V DC light bulb, and thought we found the perfect one, but turns out it only worked with AC power not DC. So, after weighing our options, we decided to hack an incandescent light bulb and insert LEDs inside of it in place of the filament.
So, I got to work cutting off the end of some light bulbs. One thing that helped was running the end of the lightbulb against a belt sander, which chipped away at the ceramic bottom. Next, I took a hammer and chisel and carefully picked away at the ceramic end, removing the pieces with a needle nosed pliers. After the end was removed, I inserted the chisel over the filament and gave a light tap, which broke the bulb. In order to get the bulb and filament out of the light bulb, I had to chisel away at an angle at the glass lip. After a while doing this carefully, it all came out. I used needle nose pliers to grind away at any sharp pieces left over.
Here is a very helpful tutorial that I consulted throughout this process.
So, it turns out that when you break open a nice soft white diffused light bulb, all the glass shards scrape away at this white coating on the inside, and all the diffusion turns into little bits of dust. In light of this fact (haha), we decided to use clear light bulbs, and then spray on fake snow to give it back diffusion. This turned out to be a little bit of a process, namely, because ITP doesn’t allow spray paint on the floor and there is no spray booth. So, we went out guerilla style to an alley and tried out our spray technique.
It looks pretty good but up close not so much
So we noticed that we weren’t getting a very even spray, and that there were a lot of drips happening. Apparently spray paint condenses in cold weather, who knew! Luckily, we were doing this nonsense right outside of NYU’s Scenic Design shop, and a nice man happened to see what we were up to and asked if we wanted to use their spray booth. We happily accepted, and the rest was pretty straightforward. Hold the can about 10-12 inches away, and do a bunch of coats. A warm environment makes for nice happy spray paint, and no drips!
When we started talking to people about this project, namely that we wanted to translate the voltage signal coming off cassette tape into light, the name Eric Rosenthal kept coming up as someone “we should talk to.” Eric Rosenthal is ITP’s resident electronics guru. Just as Tom Igoe is an expert in all things Arduino, Eric Rosenthal is the master at all things analog. He teaches a class (that I really want to take) called Basic Analog Circuits. He basically knows anything you’d want to know about electronics.
So, we went to him to try and figure out the best way to read the signal coming off the tapehead, and translate it into light. After hearing our concept, Eric proposed an analog method to achieve what we wanted. We were really excited about this, mostly since the concept behind the project is a sort of ode to analog technologies that have been (or will soon be) retired. However, after thinking about the project a bit more, we opted to use the Arduino since it will afford us more control in mapping the input signal we get from the tapehead.
In order to preserve the signal coming out of the hacked Walkman, Eric recommended we get an 1/8″ stereo jack, which splits the signal from the ground. He also helped us design a circuit to preserve the signal, which connects one of the stereo signals to a 104 capacitor and signal diode in parallel. I’m not completely sure what they do, but I think it maintains the signal strength without actually amplifying it with an op amp, which is what we thought we had to do originally.
signal input and light output circuit
We split the signal coming out of the Walkman line out jack with a Y-splitter. One 1/8″ cable goes directly to our speaker for the audio output, and the other 1/8″ cable goes to the stereo jack, then to the signal diode / capacitor circuit, then into the Arduino. Our Arduino program then maps the input to an LED connected to a PWM pin, so that it gets brighter and dimmer according to the voltage signal.
This week we also heard about the NIME conference, which had a call for projects for a museum exhibition that would coincide with the conference and performances. We decided to enter our Media Controller as an exhibit, which was due on Friday, November 5th. It was an interesting process trying to write about the project before we had completely finished making the conceptual and formal decisions, but it also made us put down on paper what we wanted it to do, and the significance behind it. Here’s crossing our fingers we get to go to Norway!
So the second serial lab was good practice since I actually haven’t made any projects yet that really require the Arduino to talk to Processing. Hopefully I can figure out something I can do for the final that incorporates both.
I am starting to understand the difference between BYTE, DEC and other serial values, but this chart is still immensely handy. The code for the lab that sent the sensor values in “many formats” was especially helpful to compare the different characters (and see how they’re related.)
Code:
int analogPin =0;
int analogValue =0;// integer to print
void setup(){// open serial communications at 9600 bps
Serial.begin(9600);}
void loop(){// read the analog input, divide by 4:
analogValue = analogRead(analogPin)/4;// print in many formats:
Serial.print(analogValue, BYTE);// Print the raw binary value analogValue
Serial.print('\t');// print a tab
Serial.print(analogValue, BIN);// print the ASCII encoded binary analogValue
Serial.print('\t');// print a tab
Serial.print(analogValue, DEC);// print the ASCII encoded decimal analogValue
Serial.print('\t');// print a tab
Serial.print(analogValue, HEX);// print the ASCII encoded hexadecimal analogValue
Serial.print('\t');// print a tab
Serial.print(analogValue, OCT);// print the ASCII encoded octal analogValue
Serial.println();// print a linefeed and carriage return
delay(10);}
Multiple Sensors communicate Serially
So I wired up my Arduino with multiple sensors: a potentiometer, an FSR, and a switch. In order for my switch value to appear in the first part of the Punctuation section, I had to declare it an analog input instead of a digital input, since the code was set up to go through three analog inputs and print all the values. It still gave me a digital reading of 1 or 0.
void loop(){for(int thisSensor =0; thisSensor <3; thisSensor++){
int sensorValue = analogRead(thisSensor);
Serial.print(sensorValue, DEC);// if this is the last sensor value, end the line.// otherwise, print a comma:if(thisSensor ==2){
Serial.println();}else{
Serial.print(",");}}}
Next came “Hand-shaking” or “Call and Response.” I can see the benefits of this method, as I don’t think they fill up the buffer as much as constantly sending serial data does. That said, I’m still at the “copy and paste” stage with this code, and don’t completely understand the logic behind it. But I did get it to work, so that’s something. One thing I had to do was map the sensor values to the width and height of the Processing screen, so that they’d be more visible. Other than that, this lab was pretty straightforward.
Next we wanted to see if we could “explode” the Walkman and still read the tape head. To do this, we unscrewed as many screws as we could find, then used shears to cut away at the plastic casing. A few times we accidentally snipped important cables, like the one connecting the tapehead to the amplifier, or the one powering the circuit board. Proceed slowly is probably the best advice I have.
By connecting a 3V power supply (the voltage recommended on the back of the Walkman) to the battery terminals, we were able to supply the playhead with power so that it read the tape. By connecting the line out jack on the walkman circuit board to a speaker we could hear that signal as sound.
Powering the hacked walkman -- it still works!
In order to get a better sense of the signal coming off the tape playhead we hooked it up to an oscilloscope. An oscilloscope allows you to visualize an analog signal. You can actually see the voltage signal visualized as waveforms on the oscilloscope screen. This helped us determine in a more exact way than using the multimeter what the changes in voltage we have to work with are (in order to turn the light on and off).
Here’s video of the oscilloscope graphing the tape playhead signal:
After getting confirmation that what we want to do is possible, we decided to focus on the interface that we want people to use to play the tape. We had a few directions we wanted to go in. One idea was to have the tape static and have the playhead move over it. This is similar to what Nam June Paik did in Random Access Music, as well as the Analog Tape Glove project.
We liked the idea of having the tape move across the playhead in a way that required the user / listener to control it by hand. One idea was to cut the cassette tape and pull it out of the case over the playhead, in a gesture that slightly mimics having to deal with tape that has gotten loose from its cassette. However, instead of being ruined, we wanted to show that there is still information on that tape that could be read, even if the quality is slightly degraded, and, that this information could be translated into a different form.
We also wanted to see if we could make some sort of hand crank system to play the tape back and forth over the playhead. This method is proving a bit more difficult since it’s pretty hard to maintain the tension of the cassette tape when it’s out of the cassette. We’ll see if we can come up with a system in the next few weeks that can turn the tape spokes. Stay tuned.
In order to experiment with some different techniques to route the tape over the playhead, we mocked up a quick study to see what parts and routes worked best. We used the tape-pulling interface to start, as it’s the most straightforward and easiest to put together.
Scrap wood, plastic casing, and lego parts come in handy
This layout seemed to provide the right amount of tension, but not too much so that the tape would crinkle or get stuck as we pulled. The further apart the pivot points are, the harder it is to pull the tape.
This week in Physical Computing, one of our assignments is to observe a piece of interactive technology located in a public place that multiple users interact with. I went with Fred Truman on a little jaunt to Times Square since our first idea we were both excited about was to see tourists use the “Interactive Map of New York City,” located in the New York City Information Center on 7th Avenue between 52nd and 53rd. However, upon arriving at the Information Center, we discovered we were the only ones there! Apparently tourists rely more on Google and guidebooks than interactive touch screen displays to tell them where to go and what to see. It was a bit hard to believe when the guy working there said there were between 500 and 1000 visitors per day, but I guess we can take his word for it. We played around with the map for a little while (there could be a whole other post on its functionality) but decided that we needed to observe some technology with multiple users interacting.
So, we switched gears and decided to observe the subway entrance turnstiles. We picked the Times Square subway stop for the volume of traffic, as well as our assumption that it would give us a good array of subway users, from newbie tourists to seasoned veterans. We found a nice perch, and sat for about 10 minutes, during which we probably observed hundreds of people entering the subway.
the gatekeepers to the nyc subway
After people have obtained a Metrocard (an experience with interactive technology itself), they proceed to the subway turnstile in order to enter the subway. The first obstacle is locating the Metrocard on your person. Native New Yorkers seem to have their Metrocard placement down, so it’s easily locatable as they enter the subway station, and in their hand by the time they reach the turnstile. Usually this involves reaching into a pocket or quickly digging around in a purse or backpack. Once they reach the turnstile they swipe and go through the barrier in one fluid motion. The whole process takes about 2 seconds. This is how a pro does it, or someone who has been slowly trained over time to conform to the technology.
Others we observed had more difficulty. When they approached the entrance, the first bout of confusion was figuring out the right way to swipe their card. Most often people seemed confused about the direction the card should face, as I don’t think it’s specified on the machine, only on the card. This seems to reflect Norman’s point of natural design, where functionality should be visible to people at first glance, and shouldn’t require a period of trial and error.
Can you figure out how it works from the card alone?
When people swipe their card, they need to push through the turnstile in order to get through in enough time. However, when their card doesn’t get read properly and the turnstile doesn’t turn, they bang their stomachs against the bar and then have to look back to see the display in order to figure out what the problem is.
In addition to an ill-placed display system, the subway turnstiles are also designed with a sound output. However, since the beep sound is fairly long (about 1 second), and since multiple entrances are located so close to one another, the sound doesn’t necessarily correspond easily to one person swiping. Instead, a chorus of beeps layer on top of one another, adding to the general sound pollution of the city. Also, I’ve been told that there are different sound feedbacks for different card readings: one sound for a successful swipe, another sound for a failed swipe, another sound for a metrocard with a low balance, and yet another for a metrocard with no balance. It might just be my inability to differentiate these sounds, but I haven’t really been able to tell the difference between any before.
Norman’s principle of mapping describes the way in which feedback should correspond to a user’s action in an obvious way. The beeping of the subway turnstiles as they are leave a lot to be desired in terms of mapping user feedback in a useful way.
Here is the video we took of people entering the subway at the Times Square subway stop:
For this week in Physical Computing, we got Processing to talk with the Arduino, via Serial port. I wired up a breadboard with a potentiometer and sent its signal into the Arduino’s analog pin 0. Then, in Processing, I imported the serial library so that it would recognize data coming into it over the serial port. In setup(), I printed the possible serial ports, and told Processing to listen to the first one (port 0 – though this is different than the analog input pin0). Then, in a loop called “void serialEvent()” Processing read the Byte values coming from the sensor, and graphed them as a line. The lines I got with my potentiometer were really smooth and regular, so I swapped the pot out for an FSR, which gave me a little more variation and “noise” in my incoming values.
Here is my analog sensor (FSR)
And here is Processing's graphical output of the sensor values
And here is the code I used:
/*
Sensor Graphing Sketch
This sketch takes raw bytes from the serial port at 9600 baud and graphs them.
Created 20 April 2005
Updated 5 August 2008
by Tom Igoe
*/
import processing.serial.*;
Serial myPort;// The serial port
int graphXPos =1;// the horizontal position of the graph:
void setup (){
size(400,300);// window size// List all the available serial ports
println(Serial.list());// I know that the fisrt port in the serial list on my mac// is usually my Arduino module, so I open Serial.list()[0].// Open whatever port is the one you're using.
myPort =new Serial(this, Serial.list()[0],9600);// set inital background:
background(48,31,65);}
void draw (){// nothing happens in draw. It all happens in SerialEvent()}
void serialEvent (Serial myPort){// get the byte:
int inByte = myPort.read();// print it:
println(inByte);// set the drawing color. Pick a pretty color:
stroke(123,128,158);// draw the line:
line(graphXPos, height, graphXPos, height - inByte);// at the edge of the screen, go back to the beginning:if(graphXPos >= width){
graphXPos =0;// clear the screen:
background(48,31,65);}else{// increment the horizontal position for the next reading:
graphXPos++;}}
For our Media Controller project, we’re trying to read the analog signal off cassette tape, and then translate this information into a different form. Our first step was to try and see what sort of signal we would be getting out of the Walkmen. We used an 1/8″ mini headset jack, and cut off one of the ends so that we could attach it to a multimeter and see what the difference in voltage was. We got readings between about 0.5 volts and 1.5 volts:
We hope to translate this voltage signal into another form, most likely light. We might make an LED go from dimmer to brighter, as a visual way to see the voltage changing as it reads the tape
Next, we wanted to see what it would sound like to move the tape over the playhead ourselves, instead of having the walkman gears control the playback. It sounds pretty similar to scratching a record.
Testing hand-control playback with the walkman
The sound quality of the video isn’t wonderful, but you get an idea:
And here is a walkman with the gray casing removed, with the playhead touching the tape (Tumi, music of the Spirits is a wonderful gift from the junk shelf):
For the media controller project I’m working with Emily Webster and Ju Yun Song. We bounced around ideas for a few days, and finally came to the conclusion that we were all excited about working with analog cassette tape. This analog form of media storage is on the way out. Just the other day, Sony announced that they would stop making tape cassette Walkmen!
We want to work with this analog technology and see if we can turn the data recorded on the tape into another form, possibly light. We’re also interested in designing an alternative form of playback, so that instead of playing the tape inside the walkman, people could control the playback themselves.
After doing some research, we found a bunch of interesting projects involving alternative tape playback. Nam June Paik made Random Access Music in 1963, where the tape is mounted to a static surface, and the viewer moves the playback head over the tape themselves. Another nice project is Analog Tape Glove, by Signal to Noise.
Talking to a few other students about our project, we realized our very own classmate Michael Colombo also hacked a tape cassette player for a project called TapeScape. Here is a link to an Instructable about his project.
We’re not quite sure what the interface / interaction will be yet. We’re debating between having the tape be static but the playhead move around, as most of the above projects, or move the tape over the static playhead in some way. A nice example of this project is Joe Winter’s piece One ship encounters a series of notable exceptions. Video of the piece in action below:
My stupid pet trick is finally complete! In light of the assignment, I made a “digital neon” sign that tells the viewer whether they are ‘hot’ or ‘not.’ Interestingly, I wasn’t the only one in my class to have such a shallow (but hilarious!) idea. Matthew Rader made a “hot or not” detecting flash device.
that's hot
I created the digital neon effect by aiming two super bright LEDs through a piece of 1/2″ diameter acrylic rod. I experimented with different lengths of rod, and 5″ seemed to be the right length so that there was no dim spot in the middle. Next, I sanded the outside of the rod so it diffused the light through it. I also drilled holes into either end so that I could inset my LEDs into the sides. This served a dual purpose of bouncing the light through the tubes, as well as holding the tubes in place.
closeup of LED inset into acrylic rod
Anyway, after getting some advice from my professor Tom Gerhardt and classmate Toby Schachman, I decided to mount my acrylic rods into foam core, so that the LEDs are actually what’s holding them in place. I’m pretty happy with the way this turned out since, a) I didn’t have to break out the hot glue gun so no messy glue stuff, and b) it would be fairly easy to disassemble if I wanted to repurpose / refabricate the digital neon.
When no one is standing in front of the sign it cycles through a default animation, lighting each vertical rod one after the other, in an effort to attract viewers to stand in front of the sign. An IR proximity sensor mounted to the bottom of the sign detects if a person is standing in front of the sign. This causes it to flash a few times in order to “measure” the person, then it displays one of two messages back to him/her: “Hot” or “Not.”
IR proximity sensor on bottom of sign detects a person's presence
I was originally going to use a lower profile IR emitter and detector pair. They were working to detect motion at some point (see “Stupid Pet Trick Progress Post”), but eventually proved way too finicky and unreliable, so I switched to the more robust IR proximity sensor.
Many people have wondered how the sign can tell whether you’re attractive or not. Let’s just say it involves some pretty complex computer vision algorithms that compare the various ratios of the width vs height of your facial features….NOT! It’s random. Cuz that’s just funnier anyway.
Here's what the mess of wire guts looks like on the back
