At the heart of this project is the computer. The computer is connected to a variety of other devices. Live video is input, microphones are connected, and our custom laser/receptor sets are also connected. The computer processes all of this data via our custom software, outputting live video and processed and/or prerecorded sound.

The software used for this project was created by Luke Dubois and Karl Ward using the Max/MSP programming environment on the Macintosh platform. The software currently runs on an Apple G4 desktop computer.

The software can be best understood by analyzing the different subsystems within the body of software we've constructed for this project.

1. Gathering sound from the performance - The software continually receives sound from the microphones on the performers. It stores the sound in a five second sound buffer, which we'll call the analysis buffer. When the analysis buffer is full (i.e. when five seconds have elapsed), the buffer is analyzed for the loudest point in the five seconds of sound. The loudest point (based on RMS amplitude, not absolute amplitude) is determined, and the software extracts that loudest sound and stores it in one of six sound buffers. The six storage buffers are arranged in a last-in-first-out (LIFO) data structure, so when all six buffers are full, the oldest buffer is overwritten. Also, the analysis buffer is cleared after the analysis is done, to make way for the next five seconds of sound.
2. Placing sounds into rhythmic patterns - Once the loudest sounds from the successive five second analysis buffers have been stored in the storage buffers, the software places them into rhythmic patterns. The rhythmic patterns can be determined in a number of ways. First, rhythmic patterns can be pre-programmed by supplying the software with a text file containing instructions for which sounds to play on which beats of the pattern. Also, the computer can create a pattern at random. For instance, the computer can pick two random numbers (one for the buffer number and the other for the beat number), and then assign that buffer to that beat. Also, we have created an algorithm which, during the analysis stage, calculates the beat on which loudest sound occurred, and then places the sound on that beat. This allows the dancers direct control over the rhythmic pattern itself.
3. Gathering data from the laser/receptor hardware - Please read the section on our custom laser/receptor sets before reading this description. The receptors are connected to Douglas Repetto's customized Peavey MIDI slider box. From that box they are connected via USB to the computer, which receives their data using MIDI. Our software sees a stream of numbers coming from each receptor. These numbers correspond to the amount of light hitting the photocell inside each receptor; high numbers (like 100) mean more light, low numbers (like 0) mean less (or no) light. The software is written to detect when the value for a receptor falls below a certain threshold. Whenever that happens, it indicates that something has passed between the laser and the receptor, thus breaking the beam of light cast across the stage by the laser. When the value for a receptor returns to a state above the threshold value, it indicates that the laser is hitting the receptor, which means that whatever was blocking the laser is no longer doing so.
4. Using data from the laser/receptor hardware - The state of the laser/receptor sets, determined as stated above, is used in a variety of ways. The simplest way to use the laser/receptor sets is to "attach" each receptor to a sound file, which is played whenever the laser beam is broken. Or, breaking the beam can be used to unmute an already playing sound, so that the sound is only heard when the beam is broken. Also, rather than just use the state of a beam to trigger events, the frequency of changes in the beam's state can be used to affect parameters of the sound, music, or video. For example, when many beams are being broken more than two times in a given period of time, this could trigger compositional changes in the video, such as a shift between live video and prerecorded video.
5. Generating and converging multiple tempos - One section of the piece required the convergence of multiple distinct tempos. This section introduces three distinct tempos, which at first have no correlation. The software calculates the average tempo from these three tempos, and then slowly increments each toward that average. Eventually, these tempos are adjusted enough that they all converge to the average tempo.