GotRhythm?, our midterm project, lives and now has it's own web presence in addition to the development Wiki. Visit it here.
posted by Amanda @ 10/24/2007 09:33:00 AM, ,
ICM Midterm - Crosspost
Monday, October 22, 2007
For my icm midterm, I was to implement only one step of a larger project. Wanted to cross-post here because I incorporated physical computing into my project.
It was initially my intention to create a project involving visualizing poetry parsed from XML on the web. The part I chose to implement was the actual motion that I wanted in the end. For the purposes of this first phase, the lines are being pulled from three text documents that live locally on my computer. The line motion is created by three potentiometers sending bytes to processing serially. Each text file contains one poem and they are not related. The values received from the Arduino are subtracted from the X position of each line respectively, creating a leftward motion across the screen. When the line leaves the screen, the poem is incremented by one line and a new one enters from the right. The user can use the potentiometers to alter the speed.
My project evolved into being a tool that a poet, or any artist really, can use to combat a block in creativity. Though not intended to provide lines to a writer, the program can juxtapose existing lines from poems in such a way that one's creativity may be triggered. In essence, the versifier is intended to be a writer's block buster. Once off the screen, the lines cannot be retrieved and brought back on screen (there is no movement toward the right on the X-axis). This is intentional as the versifier is meant to encourage experimentation and to discourage attachment to specific lines or groups of lines, especially since they have been written by someone else already.
The physical element is meant to invoke a blank sheet of paper, as is the screen, which is bare except for the three lines in play.
The program running:
posted by Amanda @ 10/22/2007 09:46:00 PM, ,
This week we are working primarily on finalizing our rhythm training tool for presentation on Wednesday. Our project Wiki can be found here. In addition to the Wiki, there will be a more formalized set of documentation completed for Wednesday's class for those who might be interested in what we ended up with and how we got there.
posted by Amanda @ 10/21/2007 02:04:00 PM, ,
Midterm interface
posted by Amanda @ 10/15/2007 11:38:00 PM, ,
Lab 6 - DC Motor Control
Sunday, October 14, 2007
This lab was slightly more complex than those we have done in the past few weeks (though it used no serial communication). The H-bridge has sixteen pins and we used 11 or 12 of them here. Additionally, it was necessary to have two power sources.. both the 5V from USB and 12V from the wall. Initially interpreting the schematic was a challenge, but taking it step by step, I thought I had figured it out. I went through my board step by step, looking over the schematic again and again, but no matter what I did, upon adding power, nothing happened. The LED flickered initially, quickly blinking three times, and then nothing. I changed my board around, looked at the schematic again read through the lab again.. and nothing. Reloaded my code numerous times, again a quick flicker of the LED and then nothing again. Since we set the motor to run in alternating directions, depending on whether its pins were set high or low, it should have run at least a little, in some direction. Eventually, I brought some other folks to look over my board and check my code. I switched the pins and again, nothing. Using a multimeter and checking every connection, eventually Tymm helped me to realize that in fact my H-bridge was faulty. He lent me his and it ran perfectly.
I hacked a fan that I got as a promo giveaway at a party, and attached it to my motor. Having a hard time uploading the video, but will shortly.
posted by Amanda @ 10/14/2007 08:29:00 PM, ,
Midterm Prototyping
Here are some pics from one of our midterm prototyping sessions. Initially, we began our project as one which would be built upon the model of a marimba. We were playing with the ideas of both having an instrument and a learning tool (almost like a Simon) for memorizing melodies. Gradually, and after prototyping both ideas (we did not create one model, but rather opted for two) we decided to proceed with the learning tool as a method for learning basic rhythm. We had worked to develop both a drum-pad like device and a system contained withing a mallet, or striker. Tymm worked on the mallet and produced an instrument that produces ethereal beautiful sounds, but we are opting to go ahead with the learning idea and going with the drum pad idea. We all liked the idea of a tool that would encourage interaction and give feedback - though we are still in the prototyping stage, ideally we will go forward and create an instrument through this framework as well .. one that allows the user to improvise and be spontaneous. At this point we are focusing on the interface and the functionality..so far it's just really quarter notes, to be developed into eight and then sixteenth.
We started to develop the pad using piezos and experimented with a number of materials as housing, settling eventually on neoprene and part of an anti-static mat. The combination of the materials, housed in an empty candy tin, allowed for enough vibration for the piezo and gave good readings. Initially we had cut cork as a playing surface, but it was way too absorbent and killed our readings from the Arduino - they were totally uneven.
Our piezo hook up:
Readings were steady (reading everything above 50 in serial) when striking on the table:
Cork was way too absorbent:
Using neoprene proved a good alternative (tried it initially using my laptop bag). We bought a number of cheap mousepads and cut them to size. The readings from that point on were useful and steady.
Since our primary observations were based on the instrument model, I have been looking into rhythm learning methods and different kinds of toys and games for this. It's also been helpful to look at videos online of different tempos.
A couple of additional things that we need to keep in mind throughout this process:
As Tom pointed out in class, syncopation needs to also play a role.
Tymm was talking about how he has rhythm but is sometimes off-sync when trying to keep a beat, i.e., he comes in on the wrong beat and then is always off. We are trying to work this into the software -- to have it recognize every fourth quarter note as unique.. versus just tracking every quarter note.
posted by Amanda @ 10/14/2007 06:32:00 PM, ,
Lab 5 - Serial, again
Tuesday, October 9, 2007
I worked on my code this morning with Tom and decided to take another stab at the serial lab. It turns out that the ball on my screen was acting sporadically because the bytes that were being received by my Processing sketch were being received out of order (or more accurately, out of synch). To combat this, we added a piece of code that told processing only to starting using bytes after one full cycle had been sent. We worked in the serialEvent:
void serialEvent(Serial myPort) {
// read a byte into the sensor value array:
int inByte = myPort.read();
if (inByte != 255) {
if (firstContact == true) {
sensorValues[i] = inByte;
}
i++;
}
else {
println (i);
i=0;
firstContact = true;
}
}
This, along with a few other tweaks, helped my program to run smoothly. I created a little game, almost like a digital etch-a-sketch to take the lab a little bit further.
I put together a digital etch-a-sketch kind of machine - here's an, albeit poorly shot little video of it in action:
posted by Amanda @ 10/09/2007 11:46:00 PM, ,
Lab 5 - Serial
Saturday, October 6, 2007
Lab 5
For the purposes of this lab, and the basic steps, I am working with two potentiometers, a push button swtich and 10kohm resistors. I connected both sensors (pots) to my arduino and board at analog pins 1 and 0. My switch is connected to digital pin 2. This lab presents an opportunity to incorporate all of the elements of the last month's labs.
Step 1, which simply shows how data is formatted when it is sent serially is shown below. When the pot at pin 0 is turned all the way to the left - the serial output reads 120. When it is turned all the way too the right, it reads out at exactly 255 (exactly what one would expect) - the analog value is divided by 4 in our code to yield this result.
Changing the analog value from DEC to BYTE gives us entirely different results. The equivalent of the 255 readout is now a "y" with an umlaut (sp?) over it. Turning the pot to the left changes the character, but it's still not decipherable. We are seeing the raw binary value.. The BYTE modifier doesn't format the bytes. If the sensor's value, divided by 4, is 255 our new arduino code must have sent 5 bytes? One for the 2, one for the first 5, one for the second 5, one to move the cursor down, and one for the carriage return. Can this be correct? Using the ASCII table, I'm not quite sure how to interpret this data.
The next part of the lab has us sending the values as many different formats at a time (which I didn't even know was possible). Using the lab code, the readout now looks like this (I left the pot turned all the way to the right so it is easier for me to compare this data with earlier data) It's now printing the raw binary value, ASCII-encoded binary value, ASCII-encoded decimal, hexadecimal, and octal values:
For the next step we are adding our other two sensors (one analog, one digital) to read all three. Our code yields nothing in the serial monitor. Our new code indicates that nothing is to happen until a byte is received, so no readout. I need to find and figure out the Terminal program! I found the terminal program using spotlight. It's just sitting in my applications folder. Who knew?
I got into the terminal program, found my serial ports, entered the code I thought I needed to enter, and ended up with a crazy error message in Arduino: 
I closed Arduino but was unable to go back and type into the terminal app. Closed Terminal, reopened, entered the code again and am now getting an error in the terminal app:
sorry could not find pty
[screen is terminating]
Feeling a little frustrated. Have quit out of both Arduino and Terminal multiple times. Am now trying to go directly to the Processing portion of the lab. Get an error message there too! 
Just talking to some people in the lab, and they suggested restarting my machine altogether. I'm going to give that a shot. More in a minute.
Restarted my machine, restarted terminal, processing, arduino. Tried both the call and response and punctuation method. Continue to receive error message: gnu.io.PortInUseException: Unknown Application
at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354)
Asked around the lab - finally found someone who understood my error messages. She went into my processing library and installed something that allow it to interact with my serial port. I finally got the ball to move on screen as a result of the movements of my pots! So far the switch doesn't have any effect. I'll need to take a closer look at my board.
posted by Amanda @ 10/06/2007 01:24:00 PM, ,
Midterm Observations
Wednesday, October 3, 2007
Midterm Observations
The action that we Josh, Tymm and I have chosen is striking an instrument with a mallet to produce sound. We also wish to incorporate a learning environment (deciding between melody and rhythm training). The medium being changed is the sound itself.
The action is taken on the instrument itself, which will be roughly modeled on a marimba or other idiophone. It will be a table-top instrument with a smooth surface for striking. A striker, or mallet, will be held in each hand.
The goal of the activity in this case will be two-fold. The goals will be to produce music and to learn as well. We are still in the process of figuring out this aspect of the project. The ultimate goal (and ideally this will take place after learning) will be to produce music that is pleasing to the user and perhaps his/her audience.
The person stands in one place initially, with feet roughly shoulder width apart.. their hands are actively engaged with the instrument and holding a mallet in each hand. The head is cocked down at a 45 degree angle (roughly) and concentration is focused on both hands. As the playing begins and continues, the person engaged in the activity tends to shift his or her weight and increase movement in the feet.
Standing for long periods of time could be boring or uncomfortable for the feet. Additionally, focusing increased attention on the instrument, with one's head down, can cause cramping.
We are experimenting with placing sensors in both the strikers as well as the instrument being played. The angle of the mallets will alter the sound that is produced. The actions taken in playing this instrument mirror the characteristics of sound in that force produces increased volume and changes the sound (pitch?)
Often, players of these instruments will use more than one striker while they are playing to hit more than one note at a time.
specific observations
user is using instrument for 1 minute
standing straight
eyes always down
pivoting at the waist for increased reach
occasionally takes one step to the right or the left
holding mallets so pinky finger is approximately two inches from the base
thumb is securing mallet so it doesn't fall
user is bent slightly forward from the waist
looking directly down at instrument from above
feet either shoulder width apart or in a “v” formation heel-to-heel
action is generally more from the wrist - pivot at the wrist with elbows tucked in at sides
sometimes, but less frequently, action is initiated at the elbow.
if playing with two mallets in one hand: mallets are held in a closed fist position, with one extending between the pointer and middle finger and the other extending between the ring and pinky fingers. the ends of the mallets are joined within the closed fist in the v formation.
user changes the angle at which the arm approaches the instrument to vary the distance between the two keys played.
posted by Amanda @ 10/03/2007 09:26:00 AM, ,
Lab 4 - The Servo
Lab 4
This week we incorporated elements from the earlier labs and adding a servo. I chose to use my sonar rangefinder again as my analog input device. Josh and I worked on the lab together - initially we used the code provided by Tom for the lab and then experimented with different elements to change the behavior of the servo.
We experimented quite a bit with the minPulse, maxPulse and analogValue, changing that line of the code from
pulse = (analogValue * 19) / 10 + minPulse;
to multiply by values from as low as 5 to as high as 100. From my observation, this conversion of the analog value had the strongest effect on the servo's behavior.
posted by Amanda @ 10/03/2007 08:41:00 AM, ,
Midterm research
Tuesday, October 2, 2007
Midterm Research
For the midterm project, Josh, Tymm and I are working on a musical instrument.. different from any that exist, but most closely related to a marimba. Accordingly, I've been watching marimba videos all day. Here are two of my favorites:
posted by Amanda @ 10/02/2007 10:48:00 PM, ,
Fixing the broken
I went back to last week's lab to smooth out my values.
posted by Amanda @ 10/02/2007 08:21:00 PM, ,