Final Project: The Water Synth

Featured Posts, Physical Computing

Description:
A waterfall that functions as a musical instrument. When the user passes their hand under the waterfall, notes will play. The note will be sustained as long as they keep their hand in the same position. It will be possible to play chords or intervals (multiple notes at once) using both hands.

Prototype:
Our first prototype was as low-fi as possible–we created a waterfall by pouring a bucket of water into a tupperware container with a slit in it. As users put their hand under the waterfall, Jarone played notes on a scale from his iPad.

 

The main questions we wanted to answer in the first round of user testing were, Is this fun? and, Is the system intuitive? The answer to our first question was that people found it fun and entertaining (though there was one user tester that was displeased about getting wet). As for the second question, when we didn’t explain that it was a musical instrument, there were a few people who just sat and stared at the waterfall without putting their hands in it. This can be solved in a number of ways (e.g., a title card with instructions, or using a peg that interrupts the stream so that a note is being played in the “starting position”, or having one of us fool around with it so the audience can see how it works, etc.)

We got really nice feedback over all, with users wanting us to experiment with sensors on the y-axis, include LEDs to light the waterfall, and create individual streams so it’s more obvious where the notes occur.

Laser Testing:
After watching some YouTube videos, Jarone and I were fairly certain we could fire lasers directly through the water stream to get a nice hot spot in the water basin below (the water refracts the light of the laser along its path). However, we didn’t realize that your average laser isn’t powerful enough to travel more than about 6 inches. Since we want our waterfall to be at least 2 feet tall, this presented a problem:


After testing, we realized that we aren’t going to be able to send the laser through the water’s path, so our plan is to plant the laser directly behind it.

System diagram:

       

Midi Communication:
We hooked up a midi jack and a photo sensor to an Arduino for a dry test:

 

We’ve succeeded in getting notes to play when the photocell is covered, but we’re still figuring out how to get one sustained note. Our next steps are to fix the code and do a wet test with a laser, water basin, and photo cell below it.

Beginning the waterfall:
We got a 400 gallon-per-hour pump that was too powerful for our initial set up, so the waterfall was shooting toward the wall instead of downward. Then when we added a valve to regulate the flow, it completely killed the water pressure so rather than a sheet we got a sad little stream.

Benedetta thinks the valve was probably rated at a much lower water pressure than the pump allows for. For the time being we’ll use individual streams for each note because producing a waterfall is harder than we expected. At this point, separate streams also makes more conceptual sense because it shows the user where each note occurs. A sheet of water gives the impression of a full range of notes you can slide between, instead of integer values that occur at arbitrary points.

Concurrency Test:
We were able to not just get one sustained note, but multiple notes at the same time! Jarone says the next thing we should do is put all the notes into an array to clean up the code.


The Second Prototype:
When putting together our second prototype, we struggled to find the right sensors. We first tried photocells, but their range of sensitivity was too small. Then we tried both infrared and ultrasonic distance sensors. We ended up using one of each in this second prototype (the IR sensor is the finicky one on the left):


The IR sensor was constantly giving out garbage readings, possibly because it was reflecting off the water in weird ways. The behavior of the ultrasonic sensor didn’t seem to be affected by the water. We decided that the ultrasonic sensor was the better, more reliable option.

Getting Ready for Final Class:
No luck pushing the notes into an array, but at least our wires are labeled.

labelled-wires
The third prototype:
For our final physical computing class, we really wanted to get four sensors working. Unfortunately the delays that we used to send and receive ultrasonic pings clogged up the entire system. The current state of our code only allows for two sensors. However, we made progress in terms of getting one sensor to play multiple notes, as seen in this video:


We’re still not sure the best way to “zhush” it up, other than by painting the pvc pipe. We still need to figure out the kind of enclosure we want to use for our circuit, and bring some dignity to the sad plastic basin. We also need to get a working system without using four different arduinos. But the prototype works!

The Enclosure:
We decided to make a wooden enclosure for the PVC pipe and water basin, and seal it with shellac in order to make it water resistant. Our friend Chester was extremely kind and made a model for us, so all Jarone and I had to do was figure out the measurements and assemble it.
  

Winter Show Highlights:
Jarone and I were fortunate enough to be selected for the ITP’s 2016 Winter Show! We got really amazing feedback. Even though many people needed coaxing to actually roll their sleeves up and get wet, they really enjoyed it once they did. The water synth was a hit with basically every demographic, from toddlers to senior citizens. We had a few professional musicians stop by and they had fun guessing what scale we used and creating quick compositions.

Source Code:

Animating in After Effects

Animation

For this assignment, I decided to do an animated adaptation of Matt Getty’s short story When My Girlfriend Lost the Weight. I decided I wanted to use individual parts of the body as focal points for each scene, and superimpose them onto a wooden manikin.  I was interested in contrasting a living, moving body with a blank, hard surface.

One of the things that I appreciate about the story is how as the narrator’s girlfriend experiences body dysmorphia, the story’s structure becomes more surreal and grotesque. I wish I could have done a better job of incorporating this into my own animation–I think it’s better when this kind of imagery sneaks up on the audience, rather than slaps them in the face. Even though this may lose me points for subtlety, I’m glad I took a risk and tried to tell this story.

Stop-Motion Animation

Animation

Assignment: Make a 15-30 second stop-motion video.

The advice our professor gave was to think of a problem that can be solved in under thirty seconds. The first thought that came to mind was tangled shoelaces. So our group decided to animate one shoe attempting to untangle another shoe’s laces. Anthropomorphizing shoes seemed like a fun challenge.

We ran wire through the laces in order to manipulate them frame by frame. However, we realized halfway through shooting that actually getting the laces untangled would be a nightmare. So the project veered in an amusing but NSFW direction. Here is the final product:

The Slapper’s Dilemma

Physical Computing

For my Physical Computing midterm assignment, my partner Annie (Se Young) Kim and I made a Prisoner’s Dilemma game (working title: The Slapper’s Dilemma). I said that I really wanted to make a slapping machine and Annie was totally down. First we made a prototype with LEDs:

The two green lights meant that both players were choosing to remain silent (and would each receive a light slap). When one player confesses, the other player’s light turns red (meaning that the silent player would get a hard slap, but the confessor doesn’t get slapped at all). When both players choose to confess, both lights turn red, because both players get a hard slap.

Next we made a prototype using servo motors. We also adjusted the code because we wanted players to make their choice and then get slapped, instead of having the button push and slap happen at the same time. We used state change detection and also added a delay. Every 10 seconds, the Arduino would check if each player had chosen to betray or stay silent, and the appropriate slaps would be triggered. Here is what the motor prototype looks like. In the video, each player first receives a quick slap for pressing the silent button. When both players hit the betray button, each receives a long hard slap:

Annie also built a pretty interface in which we wanted to mount the prototype, but every time we tried a different wire came loose and we had to give up:

betray-silent-box
Takeaways: It would have been nice to use more powerful motors with giant slapping hands for greater effect. The small cardboard hands that Annie laser cut from cardboard were adorable, but kind of pathetic. Also, the next time I try to create any kind of game, I am soldering down every damn wire. Breadboards are not the way!