learning the ropes

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!

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.

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.

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.

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.

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.