Since comprehensive moment-by-moment specification of sound can be tedious, control is gained in two ways: 1) from the instruments in an orchestra, and 2) from the events within a score. An orchestra is really a computer program that can produce sound, while a score is a body of data which that program can react to. Whether a rise-time characteristic is a fixed constant in an instrument, or a variable of each note in the score, depends on how the user wants to control it.
The instruments in a Csound orchestra are defined in a simple syntax that invokes complex audio processing routines. A score passed to this orchestra contains numerically coded pitch and control information, in standard numeric score format. Although many users are content with this format, higher level score processing languages are often convenient.
The programs making up the Csound system have a long history of development, beginning with the Music 4 program written at Bell Telephone Laboratories in the early 1960's by Max Mathews. That initiated the stored table concept and much of the terminology that has since enabled computer music researchers to communicate. Valuable additions were made at Princeton by the late Godfrey Winham in Music 4B; my own Music 360 (1968) was very indebted to his work. With Music 11 (1973) I took a different tack: the two distinct networks of control and audio signal processing stemmed from my intensive involvement in the preceding years in hardware synthesizer concepts and design. This division has been retained in Csound.
Because it is written entirely in C, Csound is easily installed on any machine running Unix or C. At MIT it runs on VAX/DECstations under Ultrix 4.2, on SUNs under OS 4.1, SGI's under 5.0, on IBM PC's under DOS 6.2 and Windows 3.1, and on the Apple Macintosh under ThinkC 5.0. With this single language for defining the audio signal processing, and portable audio formats like AIFF and WAV, users can move easily from machine to machine.
The 1991 version added phase vocoder, FOF and spectral data types. 1992
saw MIDI converter and control units, enabling Csound to be run from MIDI
score-files and external keyboards. In 1994 the sound analysis programs
(lpc, pvoc) were integrated into the main load module, enabling all Csound
processing to be run from a single executable, and Cscore could pass scores
directly to the orchestra for iterative performance. The 1995 release introduced
an expanded MIDI set with MIDI-based linseg, butterworth filters, granular
synthesis, and an improved spectral-based pitch tracker. Of special importance
was the addition of run-time event generating tools (Cscore and MIDI) allowing
run-time sensing and response setups that enable interactive composition
and experiment. It appeared that realtime software synthesis was now showing
some real promise.
Porting Csound to a floating-point DSP is both enticing and thought-provoking. Being able to run complex Csound instruments in realtime has immediate appeal, and the floating-point intensive Csound software is exceedingly well served by the SHARC hardware and its utilities. The port could have been a simple one. However, a forward-looking audio-processing network is also one that can continually change its profile in response to audio and tactile sensing of human gesture. This naturally invited some major re-thinking.
To support flexible fuctionality and interactivity, Csound was substantially modified by dividing it into two interacting parts:
1) csound - a control or host-resident part for preprocessing the user-defined orchestras and scores, downloading both, creating ftables and sampled data tables, and managing all disk and graphic I/O.
2) dsound - a DSP-resident part for performing sustained hi-fidelity audio processing, with direct on-board audio I/O and MIDI performance sensing.
The two parts are tightly connected by a custom-developed host interface, able to handle simultaneous bi-directional streams of disk-based audio data, control data, score files, MIDI files and graphical data, while the high-fidelity audio processing on the DSP is smoothly maintained.
Given this realtime structure, the signal-processing repertoire of the original Csound was considerably extended and made more effective. Extensions induced by interactive realtime performance enable the system to operate like a modern synthesizer, while those aimed at automatic MIDI file performance enable it to operate as a Karaoke machine. The extensions are most visible in faster generators (loscil1) and better voice input processing (harmon2), along with additional effects processing (chorus, flanging). The new opcodes are identified throughout this manual by an appended asterisk (*). Instruments with these opcodes will run only with the extended hardware. Instruments without them will run in both places.
Although many of the extensions are complex, the added richness has
little advantage without realtime live performance, and many of the internal
changes were driven by the wish for high- speed response to external keyboards.
As a result, most extensions have been written in 21060 assembler language,
whose hand coding was found to gain up to 6 times the computational efficiency
of its C equivalent. The addition of profiling opcodes (clkon, clkoff)
is informative here. From all outward appearances, however, the realtime
performable instruments look just like your Csound instruments always did.
Your old favorite pieces will still run, but now in realtime, and you can
play on top of them too. This is the promise that is being fulfilled.
B.V.
* Editor's note: This edition of the Csound manual only covers the public version of Csound. The Extended-Csound opcodes are not included here since they are not part of public Csound.