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 ]

If you’re working with an Arduino NG and an SPI controlled device you’re working with is not functioning properly (an AD5206, an accelerometer, etc), you’ll need to perform surgery on your ‘NG to remove the SMD LED from digital pin 13. Idiscovered this while helping YouJeong troubleshoot her AD5206. We looked at everything from the wiring to the AD5206 chips to source code to finally the Arduino itself. The only reason I was able to figure this out is that I saw that YouJeong’s Arduino NG had an LED on pin 13 (which is one of the pins Arduino uses for its SPI interface). I noticed when trying the most basic “blink the LED” program that an LED inserted between digital pin 13 and ground was very dim. When I jumped it in parallel with the SMD LED on the Arduino circuit board it was brighter. Using a multimeter we found that the pin 13 was only giving us 1.92V when pin 13 was set HIGH.

I suggested we search for “Arduino NG SPI” and we found a thread in the Arduino forums about this issue. To rectify the problem, I removed the pin 13 LED from both of her Arduino NG boards and SPI started working properly.

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!