learning the ropes

A longer render test of the October calendar I made out of my daily ritual.

The short videos above are test composites of my daily ritual recordings from October. I like the motion of these composites, but it is clear from initial comments that some of the context is missing. It’s not clear to me what question this calendar is asking or answering. These videos present the process of meditating (albeit briefly) each day. I want the video to be true to the outcome of that process. Maybe part of the difficulty here is that I’m not sure what the outcome was just yet.

I engaged in this ritual exercise to satisfy an assignment, but also to find a way to keep praying — as a meditation. I’m interested in the pattern of words I was attracted to during the exercise, but I haven’t yet been able to see all of the words at a glance. Maybe I need to just write them out on a grid and see what happens. That’s the next easiest thing I can do to push forward.

The backstory:
Last night I reconverted all of my .wmv files back to DV-NTSC files so Final Cut Pro would be able to import them. To summarize, Robert advised me to either use DV-NTSC encoding or MJPEG (motion jpeg) B in order to work on the Mac.

I hunkered down in the AV lab this afternoon to try my hand at video again. A big thank you again to Robert Moon for helping me get off the ground with Final Cut Pro and After Effects.

A short list of things to remember:
- Whether in FCP or AfterEffects, the first thing to do is to decide on and setup the output format (resolution, aspect ratio, square pixels, etc.)
- When layering tracks in FCP or AfterEffects, the topmost is visible.
- In AfterEffects, the “0″ key tells the program to render to RAM — meaning it will composite the video tracks and playback the selected video in the “Work Area”
- In AfterEffects, it is possible to select a specific portion of the “Work Area.” This affects both render to RAM as well as exporting. If the whole composition is selected, rendering (at least for 28 clips) will take a very long time.

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.

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.

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.

I continued my experiments towards one of my final project ideas: sonifying transactions. First, I exported all of my financial data (1999-January 2007) from Quicken into a tab-separated file and brought the file into OpenOffice Calc to tidy it up. After I extracted a selection of gasoline purchase from May 2001-May 2002, I realized there was something missing from the data. I’m interested in the rhythm of the purchases against the backdrop of the days and weeks. Since I didn’t purchase gasoline daily (thankfully), I needed to write a program that would insert the rest of the days into the transaction data. Doing this by hand seemed like a big pain — especially once I start working with the full dataset. To avoid having to make the algorithm aware of the number of days in each month, I simply generated a list of dates in OpenOffice Calc and compared it with the dates in my transaction list.

[ download code ]

After filling out my data, I started working in Processing and cSound to sonify the data. Starting simply, I used oscillators of different frequencies to represent days, weeks, and the transactions. The following Processing sketch is based on a sketch I wrote for my Google vs. Microsoft experiments. The classes were overkill for this application, but they were helpful for keeping the Google vs. Microsoft program legible.

[ download code ]

[ listen ]

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.