learning the ropes

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.

This week’s challenge was to create a performative object. I was intrigued last week with Arthur Ganson’s machines and wanted to explore some of the components he used in his work.

He had an excellent gear-making video, so I decided to start there. I made a jig to form consistent gear teeth and improvised from there.

Although my object (a very early piece) was somewhat performative, I also found the act of creating the pieces performative as well — something that could engage people. As we discussed in class, part of my interest in Ganson’s machines was the juxtaposition of contrasts: precision and “organic,” rigid and malleable, machine and delicate. Working with wire is always a balance between bending hard enough to make precise shapes and bending lightly enough to avoid breakage.

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.

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.

I was really at a loss for what to present as a prepared interface. Rummaging around on the junk shelf at ITP I found the remains of a Sony compact bookshelf audio system with a 5-disc CD changer. I thought I could prepare something using the existing interface and the mechanism inside the device.

Originally, I thought I was going to make some sort of audio player, but the volume control had been salvaged from the unit.

Then, I thought I could use the trays in the CD player to pull strings and control an improvised kinetic sculpture. There was only one tray.

The following is what I came up with: using the interface and mechanism of the CD player as a filing cabinet.

I started off by making some paper “CDs” to put in the unit, but realized that it would hold the little business cards I carry around as my on-the-go notepad. The sound of the mechanism and the motion it made to deliver the cards from its electromechanical bowels was precious in an unexpected way.

For my transmission arts sketch, I decided to explore Second Life and try my hand at machinima.

I have a tiny bit of 3-D modeling experience using Google Sketch-Up, but getting the hang of Second Life was a bit complicated. In order to ease into the idea, and to try out “filming,” I searched for some potential movie sets upon which to do some goofy movie reenactment. When I discovered that there is a Titanic replica in Second Life, I decided that the silliest thing I could possibly do would be to pose my avatar in the infamous Leonardo DiCaprio pose at the bow of the ship and yell, “I’m the king of the world.”

When I “teleported” to the location, I found that several other avatars were there — including one who apparently shared my idea. I waited my turn and then tried my best to contort my avatar into the Leonardo pose. Not too easy, considering all I could use were the built-in gestures.

Next, I thought I might try my hand at some dancing. Here’s my avatar dancing away in the background… This dance floor actually pays you to dance on it… Perhaps it’s meant to look like a happening spot. The area appears to be owned by a virtual realty outfit.

My next sketch explored camera placement opportunities. I found it very interesting that Second Life’s basic interface includes very flexible camera positioning. It’s almost as if the world has been set up to duplicate a cinematically-inflected viewpoint. Real life is not dramatic enough, so let’s give ourselves the ability to pan and zoom our view of the landscape and ourselves.

That said, I enjoyed my explorations, but I don’t know that I’ll return there. Too easy to get sucked in.

Assignment:
Choose one of your senses, appendages or behaviors and augment or frustrate it technologically.

I built a device to frustrate my normal vision by forcing my eyes to look out the side of my head rather than straight ahead. Its design was inspired by animals such as the hammerhead shark, which do not look forward as humans do.

The following series of pictures document the process of designing and making two prototypes.

The second half of our class on Tuesday evening was spent working on physical theater at Judson Church. This was quite possibly the highlight of my week. We enjoyed an hour and a half of movement and really worked as a group in a way I hadn’t experienced in a class before.

I wanted to capture some of the energy of that experience, so I made some sketches yesterday evening on the bus.

It was my intention to take the Mad Libs / Karaoke machine I created for my interactive narrative assignment and deploy it in a public space.

The first problem with this is that it would require a bunch of equipment. Perhaps I could do a performance with it in a bar, but definitely not in Washington Square Park.

I started thinking about ways to move the program online and enable the collaborative “storytelling” gag I used in class. One of the ideas I had was a simple web site that would ask each successive visitor one of the questions. When all of the questions for the current “story’ were exhausted, I would be notified by email and could perform the song in a video recording and upload it, which would then notify all of the participants.

PHP and Me
The site would be driven by some PHP code, I thought. After breaking the problem into a number of small pieces, I spent a bit of time trying to work out the little prototypes:

• Loading items from a text file residing in my web directory

• Displaying a form on a webpage that could post its results to another portion of the script
• Saving users’ answers in another text file and keeping track of the current question (later working out how to deal with multiple simultaneous users)
• Automatically generating email when all questions were answered

How hard could PHP be, I thought? It was easy enough to find documentation about reading and writing files, and I got pieces of that working without too much trouble.

This is not how I should have begun, however. Eventually, I had the sense to recall Amit Pitaru’s strategy for moving forward on a project: figure out how hard it is going to be to do something before doing it. This, coupled with Wendy Richmond’s strategy to keep doing easy things, led me to type “madlibs php” into Google. No sense in learning how to write madlibs if it’s already been done. I’m not here to learn another programming language. I’m here to learn how to prototype things quickly. So… I dumped code onto my site and within moments I had a PHP-based madlibs game running. I hated it immediately. It lost the feeling it had when I performed the first version of the piece in class. I could no longer experience the entertainment of people shouting out goofy answers to the questions. The web was not a good setting for this performance — at least not as I was envisioning it.

Again, a personal admonishment that bears repeating over and over again: when prototyping, look first to find out how hard something is going to be — and whether there is already something that will get you close. Hack!

Back to the Drawing Board
I decided to search for other ideas for public pranks / performances. The following are images from my notebook. If you want to see captions, please click on the images.

I would like to play around a bit more with the LCD screen idea, since I spent some time over the summer working with character LCD screens. I’ve also started putting together my first XBee radio breadboard.