Netconsole

I'm wondering whether there's a taxonomy of interactions somewhere in some book on information theory. I have a growing list that so far contains 6 types of interaction that we could implement between machines. I've named them after the image/practice that exemplify them. The list below was started in the post on Music Of The Lost Cities . I've been modifying it since then.

1) Tabletop. People drumming on the same table ie triggering stuff on a common instrument/program. The program reacts to all the triggers independently. This is basically no different from the situation where individual players play individual instruments.

2) Light Switch. The program/instrument can be in one of a set of mutually exclusive states. Anyone can specify that state, but doing so changes/overwrites what anybody has done.

3) Stompbox. I modify somebody else's signal. A variation would be that my output would pass into the mix in parallel with the original signal.

4) Spirit Glass. The program/instrument's output is determined by multiple inputs that are averaged, or somehow combined, the way that the path of the planchette on an Ouija board is the vector sum of all the pressures exerted on it by the participants' hands. "Spirit Glass" refers to the ordinary drinking glass that Filipinos use as a planchette on an improvised Ouija board to play the game known locally as "Spirit of the Glass."

5) Dragon Dance. Parallel inputs are summed to create an output that is perceived as a single, complex output.

6) Slavery. So for instance video is slaved to the drums, so that it cuts exactly to the snare.

6) Counterpoint. For example, instead of slaving video to the snare, it creates a different pattern in the bpm of the drums. Basically acts like another drummer, creating original output based on implicit data.

For the last couple of weeks, Malek and I were working on an implementation of the Light Switch type of interaction. We used OSC, Max/MSP and Max for Live and called the project Netconsole. The idea was to make instruments that everybody on the network could control.

As an example, let's take the case of Malek coding a basic tone generator on his laptop. Although his laptop would be the one generating the actual sound, he would code the interface in such a way that both our laptops would show identical control panels for controlling that sound, just as if we were both looking at the control panel of a single physical machine. As I have already said, this was an instance of the Light Switch paradigm, as both of us had access to the control of a single machine, and any operations on it basically invalidated/deleted all previous operations, just as though we were two people fighting for the control of a room's light switch, or thermostat.

What was fruitful about this idea was that it actively courted positive feedback loops and forced us to figure out and describe ways to avoid that. More on that in the next post.