next up previous
Next: Max and Pd Up: Examples Previous: Csound

Patchwork and OpenMusic

Michael Laursen's Patchwork program [LD89] and its descendant, OpenMusic, by Carlos Agon and Gérard Assayag [A+99], offer a much tighter integration of data. Figure 2 shows a simple OpenMusic patch.

Figure 2: An OpenMusic patch (borrowed from IRCAM's documentation).
\begin{figure}\begin{center}
\psfig{file=fig2.ps}
\end{center}\end{figure}

The semantic of OpenMusic (and Patchwork) is one of demand-driven dataflow. Each object is essentially a function call, which recursively evaluates its inputs, precisely as a Lisp form is evaluated. Compared to Pd, the relationship between data and process is reversed. There is no notion of real-time events or even of real time itself; rather, the contents of a patch are static data. The paradigm gets its richness from the fact that the data types (which in the pictured example are just numbers) can in general be any lisp data structure, and so can easily describe whole sequences such as a Csound score.

OpenMusic supplies a sequencing function which, given a sequence as an argument, plays the result out the machine's MIDI port or sends it to a software synthesizer. The data managed in the patch itself are all entirely out-of-time; the sequencer's function of putting the data in time is a primitive operation. The lisp object or objects which hold rhythms, pitches, and even timbres are queried by the sequencer which does the data mining as a black box.

This is ideal from the composer's point of view, since the creation of a musical score is essentially an out-of-time activity. But performers will have little use for OpenMusic since, in live performance, the instrument doesn't query the performer, but rather, the performer sends messages to the instrument. This is the Pd (and Max) organization, the reverse of that of OpenMusic.


next up previous
Next: Max and Pd Up: Examples Previous: Csound
Miller Puckette 2004-11-10