« March 2008 | Main | May 2008 »

April 29, 2008

"Play" Documentation Pt. 2 - Construction

This post is a detailed account of the design, construction, programming, testing and presentation of my piece, "Play".

It's long, packed with pictures and video, and serves as the body of my documentation for the piece. It covers changes made from the prototype, improvements, hardware, software, signal pathing, programming and presentation. It's a long read, but worthwhile if you want to know how it all works. Included are links to download the patch and associated files.

Full post below the fold:

**All images will pop to a larger version**

The conceptual development and basic presentation for Play was completed at the end of last semester, when I presented a prototype version of the exhibit for the Fall 2007 Interactive Art studio class. Unfortunately it was a very early prototype, as some of the vital components were not delivered in time for the presentation. The software was not very refined as well, eating up all of my processor (and needing more), there were connection issues, and the sound wasn’t very pleasant. All of these issues (and a few more) I would address during construction and programming throughout spring semester.

Presentation:

The first issue I tackled was the actual beach balls themselves. These beach balls are slightly different than the standard ball, as they have a cylindrical central core that is open to the outside air pressure. As the ball inflates and the pressure inside the ball exceeds the ambient atmospheric pressure, anything contained in this central chamber gets gripped tightly and can no longer be removed. The first batch of these special balls that I ordered last semester not only didn’t come in on time for the prototype presentation, the Wii Remotes (wiimotes) wouldn’t fit in the central chamber. The wiimote was too big and the inlet hole was too small on the 12 inch ball. I needed to find these highly specialized in a larger size.

After a solid four weeks of calling shady clubbing and rave outfitters (through whom these balls are typically marketed), I finally found a corporate branding company that had a ball of similar design that was 4 inches larger than anyone else. Considering Branders.com didn’t typically work with individuals – let alone art students – they were highly accommodating to my needs. They cut the minimum order drastically, dropped the per-unit price and expedited shipping to accommodate my needs. Ordering 25 still seemed like overkill, but the ample extras came in handy very often.

The balls were perfect, except in one small detail. The wiimotes and glowsticks I needed to place in the central chamber fit perfectly in these larger, 16 inch balls, but the balls were clear.

The contents were perfectly visible, so I decided to paint the vinyl balls with spray paint and hoped that the light from the glowsticks would still shine through. Just after spring break, I applied a thin layer of white Rust-oleum spray paint for plastic to a test ball and evaluated the diffusive properties of the paint. It went very well, transforming a clear ball into a lightweight glowing sphere.

The paint itself posed problems, however. Uneven coating was readily apparent, as thicker sections of paint were darker than more lightly covered areas. The paint itself took a very long time to dry, and even when completely set the surface of the ball was slightly sticky. While drying, the balls had an unfortunate tendency to stick together, ruining fully 6 balls with paint transfer. A few generous coats of Krylon low odor clear gloss finsher handled the tackiness and paint transfer problems easily; it even imparted a nice sheen to the surface and a comfortable tactile experience.

The glowsticks I used changed from performance to performance. I had a large stock of cheap gowsticks I bought years ago in a Japanese 100 Yen shop (dollar store) in varying colors. While I thought I had enough, testing and a mis-estimation of my remaining supply made it necessary to buy suitable replacements from an American dealer. I attempted to use LED based reusable lightsticks, but fragility and weight posed to big a problem for them to be used.

Electronics and Software:

Interfacing with the hardware was very straightforward; as the hacking community at large is engrossed in pulling all the functionality they can out of the wiimote. I used the same wiimote interface as last semester, OSCulator. The software translates all the sensor data on the wiimote into MIDI control information, which is easy to import and work with inside Max/MSP. There were a few bugs in my configuration that I fixed by changing a few settings, but in the end each accelerometer has its own MIDI channel and is addressed separately by Max. Using OSCulator to do the MIDI ‘heavy lifting’ and handle wiimote connections allowed me to greatly simplify my Max patch and decrease the load on my processor, a big problem I had in the prototype.

OSC Configuration:

I constructed the final Max patch after writing numerous test patches to sandbox various ideas. Though writing these test patches (and referring to my book) I was able to scale input data, process incoming values and translate them to MIDI note data instead of control data, and even select specified values at times variable by a secondary input. What happens is the sensor detecting attitude changes is scaled from its initial 0-127 range to about 60 -85, and the accepted values are limited by the MIDI note definitions of the C major scale. How often the input is sampled is controlled by the sensor detecting roll, who’s data is scaled to 50-300 (representing milliseconds between samples). The completed note data is fed to the mtof object, which relates MIDI note data to frequency information. That data manipulates the base frequency of a standard cycle object that creates the tones that are heard. A volume slider allows direct control of the output from each ball before it hits the ambipan object.

Final Max Patch:

The ambipan object is a Max object that handles panning in a multichannel environment. It was written by engineers at CICM in Paris, and was a godsend. It simplified placing a mono source in a multichannel field, allowing me to alter the sound’s position based upon an external input. Since the object is French and the documentation is in French, it was a real challenge to actually figure out how to handle the inputs and outputs. After sandboxing the object for about a week, I was able to decipher the schemes and parameter data I’d need to feed ambipan first before it would process my sound information correctly. Ambipan required that I define my speakers using a polar coordinate system before it could output mulitchannel sound. After the speaker’s position and relative distance to a central observer is defined, the data from the yaw sensor in the wiimote is scaled and places the sound in the speaker array. An individual instance of ambipan is used for each ball, so that the four sounds can be moved separately from one another. All the outputs from each ambipan instance are fed into the same dac object, outputting sound to the multichannel interface.

Ambipan Sandbox Patch:

In the reprogram of my Max patch, I was able to drastically cut CPU usage and eliminate the sound dropouts and skips that plagued my prototype. I was able to also create a much more harmonious sonic environment, as the input limiting eliminated dissonance and hash tones. There remains some difficulty with wiimote connections, as wiimotes turn themselves off after a period of inactivity. I can’t really fix this because it’s on the wiimote firmware, but I can just make sure the periods of inactivity don’t happen by jostling the balls infrequently. In each performance I did have wiimote dropouts, but they weren’t detrimental to the experience.

The physical hardware for the piece is quite easy to set up, although it is highly specific to W131 due to the need for a multichannel environment. The wiimotes and glowsticks are connected and then embedded into the painted balls, Max begins to process the incoming MIDI data into outgoing digital multichannel sound that’s piped out over firewire. A Mark Of The Unicorn 828mkII unpacks the digital multichannel sound data into four discreet analogue outputs that are mapped to four speakers via the Marantz amplifer: front left, front right, rear left and rear right. Below is a video of me talking through the entire signal path:









Below is a picture of the presentation during each performance. The picture is significantly brighter than the actual presentation space. I provided only a gentle that this was interactive art for those unfamiliar with the concept, and generally stood back while people were engaged.

Closing:

I really enjoyed flushing this project out to nearly my full original vision for it. The only thing that’s missing is proximity sensing via capacitance, but that would have been nearly impossible using the materials I chose. While the piece isn’t necessarily as emotive as my previous work, the interaction method is cloaked behind natural interactions with familiar objects like other projects. I like working with disguised interactive methods because the familiarity of the objects involved gently cue the viewer’s interaction with the piece. I don’t have to make the interactive method obvious with switches, buttons or directions; I just let people naturally explore the piece. For “Play?, there was a small barrier for some people, as ‘playing’ isn’t really a daily habit of most adults. Usually a small comment about how you’re ‘supposed to touch it’ got most adults involved, but some were still self-conscious and confused. A small number of people missed the connection between their interactions and the sonic environment, but thankfully there were not many. I built the balls to be quite rugged so they could withstand some vigorous play, but the only attendee that really tested their limits was a 3 year old during performance 1. Unfortunately it seems that some adults have forgotten how to “Play?.

Downloads:
Max Patch - Download file
OSC Routing Config - Download file
Ambipan Sandbox Patch - Download file

"Play" Documentation Pt. 1 - Readings

A overview of the primary 'textbook' I used to assist me with my learning this past semester; "Composing Interactive Music - Techniques and Ideas Using Max'.

Briefly: it's a little old and the information is very dated. Was missing discussion of important Max/MSP capabilities that would have been helpful for my project. The book wasn't completely unhelpful, just not as helpful as I would've liked.

Full write-up below the fold:

For my independent study this semester, I purchased a book to read and work through in an attempt to increase my familiarity with Max/MSP. I found a book that I thought was perfect; “Composing Interactive Music – Techniques and Ideas Using Max? by Todd Winkler. I really should have solicited advice from other interactive art grad and undergrad students, as this book was not as helpful for my project as it seems. I thought it was a perfect book to help me, but it was only minimally enlightening.

This book was first published in 1998, but my edition is from the 2001 paperback issue, and the information was really showing its age. Since the book was written so long ago, some of the functionalities that now exist in Max are not discussed, specifically in the realm of signal processing and generation. While not expressly necessary for my project, understanding signal processing in Max/MSP would have allowed me to significantly enrich my project in the areas of tone generation and effects processing. The book seemed specifically interested in processing MIDI data generated by a standard keyboard controller, but hinted at how alternative input devices could also be utilized. These hints were quite helpful.

The book wasn’t a total bust, however. Since basic MIDI processing inside of Max/MSP hasn’t really changed much in the last few years (and the MIDI protocol has also remained unchanged), so the sections on midi handling, translating and implementation were quite helpful. Basic programming practices and processing syntax was also covered in great depth, making structuring my program efficiently a lot easier to accomplish, This was specifically helpful, as in my initial prototype I struggled with processor over-utilization and memory leaks that occasionally let to crashes. In the rewrite, I was able to reduce processor utilization by nearly tenfold and eliminate memory leaks to create a much more stable and higher performing patch.

The book also contained conceptual development sections, discussing interaction methods, performance theory and basic approaches to computer composition. Since I had my interaction method designed and my output defined before I read the book, reading these sections wasn’t directly applicable to my project but it was enlightening for my understanding of interactive music composition in general.

Overall, the book was a solid read and provided great Max/MSP programming fundamentals. I was hoping it would provide more specific advice, but the book is nearly 10 years old. Maybe the interactive art and music community can convince Todd Winkler to write an update covering the upcoming Max/MSP 5 and fill in some information about signal processing. I know I’d appreciate it.

April 18, 2008

Updates are in progress!

Synthesizing my emergent identity thoughts as they have invaded much of my work this semester. The updates will continue through the early morning (no longer night) and into the weekend. Stay tuned . . . http://emergentidentity.blogspot.com/