As part of my effort to train for the 10k Harry Chapin Run Against Hunger, I did a 5.2 mile jog this evening.  Judging by the map, I suppose it must be nice to be able to jog by the water for two legs of the route.  It’s hard to imagine those poor suckers who don’t live near accessible water – I take it for granted but enjoy rubbing it in your face.

At about mile 2, I felt like a large stomach cramp, probably as a result of eaten organic while in Europe for a month and not enough kefir.  And probably having something to do with having smoked 2-3 cigarettes while out empathizing with newly single ultimate frisbee champion Ben about a week ago plus another one two nights ago while out at the Bohemian Beer Garden with triathlon competitor Chris “Person of the Day NYC August 19“, who may also run on Sunday.  Disgusting habit.

But by mile 3, somewhere around the edge of the Plumb Beach Channel, I was feeling good.  My pace had slowed considerably, but the miles didn’t seem to make much difference after that.

If I can maintain that stamina while going up the sort of hills Harry Chapin never sung about, I’ll be in fine shape to take 200th place on Sunday.

Today marks the day when I started to understand the basics of what iPhone app development involves.

Firstly, you need the proper tools. This means a Mac and an iPhone. You must register as a developer with Apple, and then install XCode, the IDE Apple provides for Cocoa development. Cocoa is the highest-level framework (i.e. library of code) you use to develop apps for both iPhone and regular Macs. Cocoa applications are programmed in Objective C, which is a superset of C (meaning it includes everything C includes, and more). The version of Cocoa you use for iPhone apps is called Cocoa Touch. So when you say you are building an iPhone application, you are building a Cocoa Touch application for iPhone written in Objective C.

Given that I don’t know anything about C programming (except having written some AI algorithms in it the first year of undergrad), Objective C is a very foreign language to me. However, I am getting used to the basic rules of syntax. All in all, it’s not so shocking, just time-consuming to learn. Everything is very object oriented (hence the objective in the name), and while it all is easily comprehended on a conceptual level, it’s how the various facets of the language are used in practice that is difficult to grasp. That’s not so much a difficulty with the language as it is a difficulty with the Cocoa framework.

From what I’ve gathered, the flow of the application is as follows. A user clicks to launch an app. The app’s Main function launches the main thread that gets the ball rolling. This Main function unarchives a NIB file, which is basically an archived copy of a preset, frozen, state which the app should resume. The NIB file passes control to the application Delegate. The Delegate waits for the app to finish loading, and then calls up a View Controller, which loads up a View and inserts it into the Window. The View is what has all the interface elements and things that you actually see on the screen. Once the View is showing on the screen, it knows to respond to various user actions, like clicks and drags. These user actions are associated with various methods in the View Controller file.

Make sense?

My cellular carrier is Sprint.
My cell phone is a Sanyo SCP-4900

The specifications and services abailable for my cell phone can be found at http://reviews.cnet.com/Sanyo_SCP_4900/4507-6454_7-20646714.html

This week, I ordered sample PIC chips from microchip.com. They supply up to a 3 count each of 5 different types of PIC chip, which is plenty for my purposes. Although my order hasn’t arrived yet, Joan Soler kindly let me borrow a few different types.

After playing with them for two days straight, the PIC is a bit more inconvenient than the BX-24 (with which I’m very comfortable). There is no pseudo-multitasking as in the BX. This is a real drag since almost every interesting application has multiple tasks running at once. But by timing tasks carefully, this limitation can be worked around. And I can always buy 5 PIC chips for the price of one BX and get multitasking that way ;)

I also ordered samples of accelerometers and digital potentiometers from Analog Devices, although I don’t have any use for these for the Metal Petals as far as my current designs go. The accelerometers could be handy in case I decide to detect movement of the tin snips and hammer in the performer’s hands.

I’m still searching for free samples of capacitive sensors and specs on the different sensors available. My experiences with QProx digital capacitive sensors in the past have been less than stellar – their response time, sensitivity, and ease of use leave much to be desired. Still, they’ll probably be the best bet for sensing the manipulation of the metal.

Unfortunately, my goal is not to sense the manipulations by the performer so much as the final position and shape of the metal when at rest. Capacitance will be affected by the performer’s presence and proximity, which will have to be averaged out. For this reason, I think the sensors in tandem with video tracking will provide the most information on both movement and final shape of the piece.

As a backup, I may try sensing the resistance of the metal by running a current through it. As the shape is bent and cut, the resistance is likely to change perhaps more reliably than the capacitance.

The assigned reading, “Contexts of Collaborative Musical Experiences” by Tina Blaine and Sidney Fels somehow seemed to be another regurgitation of the “low entry fee, no ceiling to virtuosity” mantra with a few broad classifications of collaborative musical experience thrown in for good form.

Derek Wang, Isabela Staicut, and my tech research project focused on intoxication sensing using the SB-30 sensor. We thought we had it all under control…

The sensor	The circuit
The code	The schematic

But Tom started drinking the tequila…	…and doing lines…

Teresita wasn’t having any of it	But Isabela starting drinking too
Me	Michael
Jeff	Brett and Matt looking quite ruddy

Here are some ideas Shannon Bain and I have been throwing around for our final project. We hope to complete several of them with a common thread (perhaps all involving a concrete platform/pedestal)

locker worm
an x-y plane of buzzing motors inside a row of lockers with two locks as the controls – like a big noisy Etch-a-Sketch.

sound governor
speaker with microphone suspended above. microphone lowers to increase ambient sound level. display strives to maintain a constant decibel level in the room.

comfort zone
BMW seat strapped to a cement base with hydraulic pumps. When the ambient termperature hits room temperature, the pumps go crazy.

fascist factory
immersive environment which presents a viewer with video and audio material. The installation tries to effect changes in the affect of the subject. Using an AI learning algorithm (hill climbing, a*, neural net, or maybe even minimax) to measure subject’s responsiveness to the tactics used.

rock show
lights and explosions and a red mop of hair representing Tawny Kitane.

cellular automata locker
evolving mobile cellular automata. dual worm system. worms create buzz in locker door.

big dumb accelerometer
a big cute and dumb barebones “thing” that somehow evokes empathy based on its appearance. Inside it is a cheap home-made accelerometer (4 hall-effect sensors around a magnet with a little bit of play). Also has a voice chip, some IR proximity sensors, and a source of amplification (either via radio, or a just a built-in speaker). The big dumb accelerometer is taken to the top of a building (preferably Bobst library) and thrown off the edge. Just before it crashes on the ground, it cries out, “But wait!…”

The Idea: Interactive Flyers

For the midterm project, Jamie Allen, Shannon Bain, and I built interactive flyers for the bulletin board in the hallway. Shannon drew a beautiful picture of a chimp holding a beer can with the caption “How ‘Bout Some Free Beer, Chump?”RecyclingBin1. Like most flyers offering goods and services, this one had pull-off tabs of paper. When a user reached to rip off a paper tab, a nearby recycling bin began emmitting a musical interpretation of live samples of the sound in the hallway. Our intention was to draw the casual observer into a relationship with the flyer and the ambient sound of the hallway that would lead them to play it as a theremin-like instrument.

The technology behind The Idea

Technically-speaking, the project consisted of 3 flyers on top of conductive foam. Each conductive foam piece was wired up to a seperate Quantum QT300 capacitive sensor. The three sensors then fed this capacitive information back to a BX-24 microcontroller. The BX-24 converted these signals into three channels of MIDI messages (one for each sensor) which were then sent out through a midi interface to a laptop (suspended from the ceiling) running Max/MSP. Max/MSP used this information as input to a program (called a patch in the Max/MSP lingo) that produced the noises coming out of the speakers in the recycling bin. Click here to download the Max/MSP patch

Originally, we had built Voltage-controlled oscillators using TLC-555 timer and LM386 amplifier chips. On their own, they produced some great (but absolutely unreliable) sounds. However, once we began using the BX-24 to vary the input voltage, we found that the BX-24’s outputs were not suitable for controlling a voltage-controlled oscillator. Neither the pulseOut command nor the putDAC command produced a convincing change of pitch. The pitch from the oscillators would change a bit and then quickly revert back to a “stable” pitch which represented no input.

I suppose the nature of pulse-width modulation is not suitable for audio information since we could clearly hear the rate of pulsing. When using PWM to control lighting, we rarely even notice the pulsing of the lights, we only see a dimming or brightening of the light, but our ears are more discriminating. Another issue may have been the fact that a pulse is a square wave, and we weren’t able to totally round-out the waveform using low-pass filters. Regardless of the cause, we dropped the idea of using own home-made oscillators and settled on using Max/MSP to do the sound processing.

The QT300 capacitive sensors were relatively new and virtually undocumented, and Jamie struggled for days to get them to send back meaningful data. He ended up writing his own serial communication driver for the BX-24 from scratch (check his website for more on this). The rate at which the QT300 collects and transmits data is very slow for translating into music, and these technical difficulties necessitated a creative interpretation of the data for the sound production.

The Sounds of a Recycling Bin

The Max/MSP patch was sporadically recording live sounds in the hallway. By moving hands in front of the three interactive flyers, the casual user was able to change the playback speed of the sample (which also shifts the pitch), the starting point of the sample (effectively making it shorter), and the amplitude. These same controls simultaneously affected the pitch, ring modulation, and amplitude of a simple oscillator. The combination of the two produced a very organic, unpredictable sound. By opening the lid of the recycling bin, we were also able to get feedback between the speakers and the microphone, which is where things got interesting…

Listen to mp3 files of the crazy recycling bin here:

…and if you like that, click here: