Dream Machine 1990

What could a computer music computer compute, if we ignored any limitations of cost or technical feasibility? What would be left to talk about? I confront this question every year or so in my sleep and again at approximately 10-year intervals at CCRMA. The answer is in the music that one wants to compute, and that is how I will conclude this short essay-with a description of my own needs in composition and music research. Luckily, I am writing on this topic after a series of group discussions held at CCRMA in the spring of 1990. Foremost in our minds was the impending decommissioning of the Systems Concepts Digital Synthesizer (the Samson Box), CCRMA's workhorse of the past 12 years. This "dream machine" of 1978 is still looking pretty good and was a quantum jump (or two) in its time. John Pierce, as always, sharpened our perspective in considering the new tools that were proposed as a replacement. My move to CCRMA happened shortly after the Samson Box was installed and debugged. I am fortunate to have landed after the end of the music compiler era (which focused on MusicV and Mus10 at Stanford), which is well known to have added a dimension of tedium to the work. I also skipped having to acquire any low-level programming skills and instead learned to program the Samson Box in two high-level languages-SAIL and Pla. Entry into the art at this level was also the experience of approximately 500 other composers and students from the late 1970s through the 1980s, during which time CCRMA's computing environment remained stable, though increasingly different from the computing world at large. MIDI gear was acquired beginning in 1982 and satisfied some of our real-time needs. The spring discussions centered around recent offerings of portable, low-cost systems with digital signal processing (DSP) capabilities likely to provide Samson Box-level processing in a single-user, networked, workstation environment. The general requirements of such a system would be that the signal processor could accomplish thick musical textures in a single pass, that there would be 100 percent control of the parameters in a sound synthesis or processing run (unlike MIDI-based instruments), and that it could be programmed with high-level programming languages. Additionally, it should be capable of a musically interesting level of real-time-controllable real-time processing, as well as running considerably faster than real time when generating a sound file with its full texture resource. Texture, here, refers to a raw comparison in terms of simultaneous voices, as well as the kinds of processing which yield the illusion of complexity (fine polyphonic vibrato controls, chorusing, true localization of sounds in an ambient field). Three digital signal processors were studied in detail. The similarities provide an interesting readout of current capabilities. All three are single-user units attached to a workstation host; two of them could also act as a network synthesis server if so configured. Systems Concepts offered a new design based on fast discrete logic that would provide four times the power of the first Samson Box (in 1/20th of the space), Ariel's Quint processor provides five Motorola DSP56001 DSP processors, and the IRCAM Musical Workstation is based on two Intel i860 processors. All are modular designs based on individual boards which must be grouped to achieve a realtime synthesis capability equivalent to one Samson Box. Because of cost, it is also interesting to consider single board configurations for smaller-scale testing, prototyping, previewing, etc. All are programmed at the assembly-language-level and offer computational generality not afforded in the hardwired Samson Box architecture, though at the expense of programming complexity. The difficulty in building new instrument patches in assembly lanComputer Music Journal, Vol. 15, No. 4, Winter 1991, ? 1991 Massachusetts Institute of Technology.