How I Learned to Love A Program That Does Nothing

Opening a word processing program presents one with a blank window, typically white, in which one is supposed to enter text. The designer of the word processor takes a cue from the almost-forgotten typewriter, in which a blank sheet of paper was inserted into the carriage, and the operator of the machine was then ready to create.

The startup state of Max is the same: upon opening the program, a window appears with nothing in it. However, this window is designed to facilitate construction not of a text, but of computer music tools. In the beginning of the original Max manual, Miller Puckette wrote, "Max is for people who have hit the limit of the usual sequencing and voicing programs for MIDI equipment" (quoted in Dobrian 1990). The strategy he adopted for circumventing these limits was a program that does nothing. What could possibly be more intimidating than a blank screen that says implicitly that the user must first create instruments before making music?

From this inauspicious beginning, Max users have apparently taken up the challenge, faced a collection of components and tools represented by boxes, placed them into the blank page, connected them together to make new components and tools (called patchers), and eventually made some music. In other words, Max—the program that does nothing—offers the promise that learning it and figuring out how to create its "documents" can lead to results that are satisfying in a way that using prefabricated software would never be. I want to explore this idea, which is on one level completely familiar and yet on another both profound and problematic.

When I first saw Miller Puckette's Max, demonstrated in 1988 by David Wessel, I was working on my own blank page scheme, a program called Riff that I soon abandoned once I began working with Miller on Max a few months later. A few ideas from Riff have made their way into Max, but it was on the whole a much smaller idea that would not have been much more than charming to a few people. Riff was supposed to be a paint program in which regions of a picture could be defined as zones of mouse-driven interaction. It grew out of my previous work on interactive composition programs M and Jam Factory (both described in Zicarelli 1987) and OvalTune. These programs were not in any sense blank pages. They were embodiments of specific compositional algorithms with variables controlled in the manner of a flight simulator. (The flight simulator model was first suggested to me by Joel Chadabe in 1986, who was particularly fond of an early Macintosh Fokker Triplane flight simulator [Hill 1986].) These earlier programs were, perhaps, things that could be approximated after some construction activity in Max, but Max is still not ready "out of the box" to build these kinds of programs.

One thing I noticed was that only a subset of the features of M, Jam Factory, and OvalTune were typically used in creating pieces of music. However, because the programs were intended to be complete explorations of a particular compositional approach, there was no way to leave out those features one did not need or want. Indeed, this surplus of opportunity was something I came to value: part of what I liked to call a "confrontational approach" to a composing system. By confronting composers with controls and opportunities they might not ordinarily try, the system might be able to open up new creative paths. A person using M or Jam Factory is adopting an approach in which flexibility is traded for stimulation. Rather than viewing the computer as a way to render pre-existing, fully realized ideas, one allows the computer to affect the way one realizes the ideas themselves. It would be very difficult, if not impossible, for a system that starts with an entirely blank page to operate in this manner—especially if the system aspires to generality and neutrality.

On one level, Max decomposes the algorithms and user interfaces of programs such as M and Jam Factory into their basic elements and lets users build their own...