This paper describes FTS and how it interacts with application software running on the host. The i860 is the first inexpensive general-purpose processor powerful enough that we could consider basing a real-time computer music system on it. Before now, one had to resort to special DSP architectures, as was done for the 4X, IRCAM 's previous adventure in real-time music synthesis (Favreau 1986). The 4X combines a general-purpose "control processor" with special synthesis hardware. A 4X application thus consists of two programs which must intercommunicate in real time: the "patch," which defines the heavy numerical calculations involved in computing sounds, and the "control program," which provides parameters for the patch, usually as a function of real-time control inputs. This separation was made out of necessity, not by choice. Forcing the user to maintain two programs, in different languages, whose state must nonetheless be kept coherent, greatly increases the effort required to develop a new application or to merge two existing ones. Because of the IMW's homogeneous hardware design, a single distributed program running on the CPs, such as FTS, can do almost all of the real-time processing required (the exception is that a host computer is needed as a server to provide certain I/O). A great part of the difficulty of making music on the 4X and similar machines drops away instantly in using the the IMW. The problems of synchronization between a "smart" control processor and a "dumb" sound processor disappear entirely, leaving only the easier and more interesting problem of coordinating several, equal, high-level processors. It is in the merging of pre-existing applications that this unification between control and synthesis makes the biggest difference. Users of the 4X...

I have worked for many years on a computer environment for realizing works of live electronic music, which I named in honor of Max Mathews. Three currently supported computer programs—Max/MSP, Jmax, and Pd—can be considered as extended implementations of a common paradigm I’ll refer to here as “Max.” The Max paradigm appears to be stable enough now that a printed description of it no longer risks becoming too quickly outdated. We can now usefully assess what Max (the paradigm) does well, what it does less well, and what we can all learn from the experience. The Dartmouth Symposium on the Future of Music Software, organized by Eric Lyon, offers a perfect occasion to start this project. I’ll apologize in advance if, for obvious reasons, parts of this article might not seem perfectly objective or impartial. The many others who have worked in or on Max in its various forms and stages should all now get a chance to voice their opinions too. The Max paradigm can be described as a way of combining pre-designed building blocks into configurations useful for real-time computer music performance.

Arctic is a langu-~ge for tile specification and imp!ementation of real-time control systems. Unlike more conventional languages for real-time control, which emphasize concurrency, Arctic is a stateless language in which the relationships between system inputs, outputs and intermediate terms are expressed as operation. ~ on time-varying functions. Arctic allows discrete events or conditions to invoke and modify responses asynchronously, but because programs have no state, synchronization problems are greatly simplified. Furthermore, Arctic programs are non-sequential, and the timing of system responses is notated explicitly. This eliminates the need for the programmer to be concerned with the execution sequence, which accounts for much of the difficulty in real-time programming. 1.