Running to Stand Still

Yesterday, several people looked at my rope and pulley instrument / interface. Generally speaking, they all liked what they saw and found the interface to be intuitive. I didn't have to really explain what to do with it -- they "got it" almost immediately.

The Test Setup

- rope & pulley system connected via Arduino to computer running Max patch
- computer connected via MIDI interface to Roland M-DC-1 dance module

When my right side faces the computer, pulling the rope towards my body triggers a note on the MIDI synthesizer. Pulling the rope with increasing speed increases the volume of the note as well as a sound modulating parameter. Decreasing the pulley's speed decreases the volume and modulation parameter. When the pulley stops rotating, the system turns off the note on the synthesizer.

I also demonstrated the original performance patch which plays Jimi Hendrix's "Red House" when the rope is pulled.

Observations
- It was difficult for me to come up with questions on the spot to ask other than, "how did it feel?", "was it intuitive?", etc.

- I was hoping to observe something that would bring me an idea for the next direction, but I'm not sure if I saw something.

- I found myself explaining and demonstrating the system to generate interest in the idea even though the system was only playing a single note.
- The system needs a bit more refinement in order to demonstrate it quickly. I sometimes get flustered when I switch between modes because it doesn't work immediately. I either need to write down the steps for setting it up or fix the Max patch so it does a few more of the setup functions automatically.

- When Amit was teaching us about user testing last year, he focused on picking a particular task. What was the task I wanted tested? It was hard to get specific answers because I wasn't asking specific questions.

- The responsiveness of the system is an important feature. Right now it feels good.

- All testers found that synthesizer version of the system really needed something to happen when the string was pulled back in the direction of the sensing wheel. It wasn't clear what that something should be, though. Shinyoung suggested some sort of record scratching sound. Rui understood the technical problem I was having with mapping volume / modulation with a positive and negative motion source. But he agreed that it felt strange that nothing happened in the "negative" direction. For this reason, he found that he liked the interaction with the computer-based sample playback ("Red House") better. The sample playback corresponded directly to the motion he was making with the rope. As he pulled the rope towards his body, the sample played "forward", slowing down and speeding up as he pulled with varying speeds. When he pulled the rope in the opposite direction, the sample responded in kind.

- One of the testers was very much interested in the body motion available as a result of this system. Being a "non-musical person", she was interested in how someone moves when playing the instrument. She wanted to see the installation of this instrument afford a nice set of gestures / body movements for the user. To observe this sort of behavior, I think I may need to build another unit that can easily be mounted horizontally, vertically (or on any angle, for that matter).

- Another tester enjoyed the materials the system was made out of. He felt like he could be rough and expressive with it because it was made out of discarded materials. Because the interface was not "precious," he felt that he could play hard. He mentioned that he wouldn't feel bad breaking the string or some other part of the mechanism because he had the sense that things would be easy to fix. If I can get the knot right, this would probably be the case. The only things I really worry about in the system as it is (made out of cardboard), is a kid trying to hang off of the rope. What I've observed several times is that people playing with an interface for the first time want to play ROUGH as the developer looks on in horror.

- I want the ability to change pitches on the instrument -- but not with the pulley. I want some sort of system on the floor that allows discrete pitch selection. One of the testers agreed with this.

- There may be something important about the fact that you can hide behind this instrument (like a guitar, piano, or even a laptop)

- I am hesitant to provide speed control over the sample playback unless it has some very natural smoothing that doesn't allow it to get too much out of control. These could be done as a series of short user feedback experiments. The other trick in allowing speed control is that stopping the rope must instantly stop the sound. This is one of the affordances of the current system. This could change if I add more mass to the pulley, however. A metal pulley will definitely want to keep spinning unless the rope is heavy enough (and has enough friction) to stop it.

- It was suggested that I ask other people (non sound people) should try it out and see if they get the mapping

- Jamie suggested trying a collaboration with motion theater people (like Judson Church) to establish a type of choreography.

Posted by Michael Chladil at 11:43 AM | Permalink | Comments (0) | TrackBacks (0)

I saw this video yesterday while surfing Björk's website. It's ironic. Several weeks ago, Jamie Allen suggested I check out Michel Gondry as a reference for my cardboard work. It turns out that Gondry works with rope and pulleys, too.

Here's the original Michel Gondry reference. The Science of Sleep

Posted by Michael Chladil at 10:28 AM | Permalink | Comments (0) | TrackBacks (0)

Excerpt from a short videorecording I made to see what I looked like performing the Rope & Pulley. I've been working on the Christmas Carol all week and am not sure what I'm going to be able to present in class tomorrow night. This is a return to the original thinking behind the project, but at least I will be able to present something if it is entertaining.

In the video, the system is controlling the volume of audio playback. If I were to stop pulling the rope through my hands, the track would stop playing and the volume would decrease.

Posted by Michael Chladil at 01:02 PM | Permalink | Comments (0) | TrackBacks (0)

No, it's not an electric prod for a miniature cow... it's a work around for a vexing problem: how do I keep the optical encoder wheel securely attached to the shaft. Neither Elmer's white glue nor hot glue were keeping the part attached to the paper sleeve, so I turned to one of my other favorite building materials: wire. I created two wire prongs to put pressure on the encoder wheel so it would stay in place.

Another challenge -- I was a bit careless when I cut out a few of the layers for the pulley housing. As a result, it doesn't sit flat and it causes the shaft to bind up when the assembly is clamped down. After struggling with the thought of completely rebuilding, I realized that I could make a flexible joint to allow some play in the mechanism. Thank you, hot glue!

Posted by Michael Chladil at 01:56 PM | Permalink | Comments (0) | TrackBacks (0)

It's time to step away from the prototype and move towards a finished-looking product. Since I've also discovered that driving the mouse ball from the outer rim of my pulley causes the ball to spin too fast, I've decided to track the rotation at the shaft instead. This means I need the shaft to be attached to the pulley rather than spinning freely through its center.

I built another model in sketchup to understand how the pieces were going to fit together (and also to beef up my sketchup chops -- bad idea, but I have a nice illustration now). [ later realization: one thing that's important to remember about these exercises is to continually question major time investments --at their outset and throughout the process... Is this the real problem that needs to be solved? Is there any easier way to get the effect I'm going for? Is this essential to the project? Is this part of the essence of the project? ]

Now that we're getting down to the wire, I'm committed to cardboard as a building material, mostly as an aesthetic choice, but also because there is not enough time for me to learn the AMS laser cutting process. Prototyping in cardboard can be fast, but constructing in cardboard can be time-consuming.

Posted by Michael Chladil at 12:39 AM | Permalink | Comments (0) | TrackBacks (0)

Today I converted my pulleys to work with the new detection strategy. Instead of using the outer rim of the pulley to rotate the mouse ball, I'm going to attach the optical encoder wheel to the end of the pulley's shaft. To avoid building the pulleys again, I've decided to patch up the hole where the bearings were seated.

Posted by Michael Chladil at 01:09 AM | Permalink | Comments (0) | TrackBacks (0)

My first interest in the people scrubber system was tying a person's motion to sound playback. I started off working with a performance using Jimi Hendrix's "Red House." I envisioned walking the song in much the same was that a guitar player might "strut" their way through a guitar solo. I picture "Red House" as a walking blues. The opening lines of the song are
There's a red house over yonder
That's where my baby lives
(or something like that)

In my mind, I saw a lone guitar player climbing up a hill to reach the house. I considered how the walking motion might be used to control the playback of a song. Originally I envisioned that the walking direction would control the direction of playback (forward / backward) and speed. After building prototypes of the system, I found that the interaction was not as engaging as I had originally hoped. Jamie and several classmates had expressed a desire to see some of the tension in the performance -- a quality which my system doesn't provide affordances for. Since my system is based on a pulley, there is not really any haptic feedback

So much of "modern" music production is done using a "time line" and loops using a tiny control surface. We edit and arrange clips of audio on flat screens using a mouse pointed. I wanted to play a bit with this metaphor and create a performative music creation environment that juxtaposes the loop metaphor with macro body movements.

Posted by Michael Chladil at 01:25 PM | Permalink | Comments (0) | TrackBacks (0)

A few days before Thanksgiving and we're getting close to the end of the semester - in three or four weeks this thing is going to need to be finished. I met with Jamie tonight and he encouraged me to commit to a direction and a presentation format.

I now have a working prototype to play with.

Posted by Michael Chladil at 11:33 PM | Permalink | Comments (0) | TrackBacks (0)

I've still been constructing the physical structure of the pulley system I'm going to perform with. I spent much of Saturday building the pulleys out of cardboard and then much of Sunday trying to figure out how to mount them so I could move on to the next stage of the project, which is creating the performance.

In my zeal to create the physical presence of this project, I worked on a 3D model of the pulley holders... for far too long. When the dust settled and I put my virtual pencil down, the structure was good, but I was really concerned about having enough time to build it. Cardboard is great for prototyping, but I think there is a tradeoff. It's a very flexible material, but some of the thinking that goes into designing with it can rival the time spent trying to do precise woodworking.

Kelly helped me find a much better way to move forward: using existing cardboard boxes rather than building a custom frame. This way, I could find out if the using a mouse for the motion tracking would even work properly.

Posted by Michael Chladil at 10:07 AM | Permalink | Comments (0) | TrackBacks (0)

An initial test of the PS/2 mouse with MAX/MSP and little video action to whet your appetite for what this will eventually become.

Posted by Michael Chladil at 04:11 PM | Permalink | Comments (0) | TrackBacks (0)

After trying unsuccessfully to parse text-based serial data with MAX/MSP, I just hooked the disassembled mouse up to the computer and started using the mousestate object in MAX to read coordinates. Here I discovered that the "mousestate" object is constrained by the bounds of the screen. Once the mouse cursor reaches the right edge of the screen, "mousestate" no longer reports any changes. Foiled again.

I would have to return to interpreting data from Arduino. As I looked at the Arduino code that was reading from the mouse, I realized that I could simply send raw bytes from Arduino to MAX/MSP. I could simply send the x position, the y position, and then the button states in single byte transmissions. I could even make MAX/MSP handshake with Arduino after the three bytes were transferred to guarantee MAX/MSP would always receive the bytes in the same order.

Somewhere along the line I became confused, though. Somewhere along the line I convinced myself that the mouse would need to send more than a single byte of data to represent the positions. That was part of the problem, too. I convinced myself that the Arduino PS/2 mouse code was sending positions rather than position changes. Further frustration ensued.

I talked with Wendy about this feeling last week: getting entrenched in the technical and losing sight of the big picture. I told her I wanted to stop getting hung up on these kinds of problems because they make me feel angry. Nonetheless, I went down this road again and had to prove that to myself that I was capable of solving this problem.

The next time this happens, I think the best thing I can do for myself and my sense of wellbeing is to call someone up and get them to ask me questions about what I'm doing and why I'm doing it so I don't waste time.

Ok. Ranting is finished.

Since I spent time working this problem through, I'm going to share the solution, even though it wasn't necessary, in the hopes that someone else may benefit from it (maybe even me at some point in the future).

I was convinced I needed to send an unsigned integer for both the x and y positions from Arduino to MAX/MSP. (An unsigned integer is a positive value between 0 and 65535 which requires two bytes or sixteen bits to represent in Arduino). I wanted unsigned numbers so I wouldn't have to deal with interpreting the negative sign in MAX/MSP. I wanted all of my data going over the serial port to always be the same length. Easy, I thought. I'll simply break the two-byte integer into two single-byte characters and recombine them
when MAX/MSP receives them. But I don't think very clearly when I'm trying to work out this sort of math -- especially when I get frustrated.

Mouse X  
MSB                     | LSB
16 15 14 13 12 11 10 09 | 08 07 06 05 04 03 02 01

To get the 8 Most Significant Bits, I could divide the unsigned integer by 256, which is one more than the maximum number that the Least Significant Bits could represent. The LSB portion of the unsigned integer should then be the remainder. When I worked at Crestron, Doug taught me a lazy programmer's trick for dealing with math... Look at the extreme cases to verify that your thinking is correct.

/// Mental Interrupt ///
This blog post, while useful, is not getting me any further on things I really want to move forward on, so I'm cutting it short right here!

Posted by Michael Chladil at 03:15 PM | Permalink | Comments (0) | TrackBacks (0)

Work continues on the second "PeopleScrubber." I started off trying to make another more robust prototype so I could start experimenting with the content of the performance, but I got hung up on making the prototype. I thought I would try a combination of wire and cardboard for this prototype so I wouldn't have to do so much cutting. It turns out that making the prototype with wire was more labor intensive because each piece had to be made by hand. The last prototype I made seemed easier; I drew templates for the in Visio, printed them out, glued them onto cardboard, and then cut them out.

Jamie had mentioned using a mouse to do the tracking, so I tracked down a free PS/2 mouse on Craig's List and found Arduino code that implemented the PS/2 mouse serial protocol. Fed up with the last prototype attempt, I made a breakout connector for the mouse using a salvaged dual PS/2 mouse/keyboard jack from a computer motherboard on the junk shelf in the Physical Computing lab.

The test program ran perfectly and reported x and y movement (as deltas) as well as mouse button states. Very slick! There was only one problem: I would need to send serial information from Arduino into MAX/MSP. The test program I was working with printed out
1000010
x=123
y=-3

There were no delimiters other than carriage returns. I tried to figure out some way to interpret the strings using MAX/MSP, but I became extremely frustrated. Parsing strings in MAX/MSP is not pleasant. It's alot like parsing strings in SIMPL. Again... unpleasant. The reason I wanted to parse the strings is so I could make sure the MAX/MSP patch would interpret the values in the correct order. With the "x=" and "y=" tags in front of data, I could be sure the x and y values weren't being mixed up.

Once I started experimenting with the "=" character as a delimiter, I realized there was another problem with this scheme: the numbers could be variable lengths. This would be easy to handle using a procedural programming language, but I haven't found anything like a "mid" or "left" function in MAX/MSP. I set the project aside for a bit to see what other ideas might present themselves.

Posted by Michael Chladil at 11:49 PM | Permalink | Comments (0) | TrackBacks (0)

Today, when I wasn't on the bus or in class I was building. I took the initial work I did last night and built it up into a mostly usable prototype. I designed the pulleys and sensor mounting brackets in Visio, printed them out, and glued them directly to cardboard in order to skip tedious measurements. If you want to see more details about the process, click on any of the pictures below. They all have captions.

I presented a partially working prototype in class this evening. I couldn't figure out the direction detection algorithm and didn't have enough time to start experimenting with my MAX patch.

Posted by Michael Chladil at 11:50 PM | Permalink | Comments (0) | TrackBacks (0)

Now prototyping in earnest. I realized that older computer mice knew whether they were moving backwards or forwards. Perhaps I could use an optical encoder wheel. Time was running out, so I started working with IR LEDs and photo-detectors. I'm not sure if I have photo-diodes or photo-transistors. The parts I have are from high school -- and completely unlabeled. In order to figure out the polarity of the devices, I examine the lens of the LEDs using the digital camera, which allows me to "see" infrared light.

Posted by Michael Chladil at 10:10 PM | Permalink | Comments (0) | TrackBacks (0)

I wasn't quite sure where the project was heading, but I needed to experiment with something physical. I was considering an interface that would scrub audio at human scale; in order words, I could perform a piece of audio (or video for that matter), by attaching myself to a simulated tape reel. In this way, I could walk or run through the linear media, with the motion of my body driving the playback. My building focused on how to detect this linear motion.

I started out with a motor, thinking I could detect the positive and negative voltages it would generate as it was turned.. Arduino takes 0-5 volts on its analog inputs, though, and I wasn't sure how to convert the positive and negative voltages from the motor.

The Physical Computing book had an example of using a potentiometer to detect motion, so I tried to prototype that system.

Ultimately, what I discovered is that the modified potentiometer didn't work reliably. The "stop" I removed left a dead space in the resistance range that fluctuated as I turned through it. There seemed to be a pattern, but I felt that the code to smooth out this abnormal behavior would be prone to breaking. I needed some other way to detect rotation.

Posted by Michael Chladil at 08:02 PM | Permalink | Comments (0) | TrackBacks (0)

As I started to think about what to perform for next class next week, there were two major themes: pulling and pushing. I was also inspired by the Markov chains we studied in Algorithmic Composition. On the right is a “Monome” like board for driving an algorithmic composition.

Posted by Michael Chladil at 06:42 PM | Permalink | Comments (0) | TrackBacks (0)