The Tar Pit

It's hard to pinpoint the exact moment in time when I started looking at this -- it's probably been around three years of fiddling with the subject on a more or less consistent basis, and of practicing in order to get some grounding. In any case, I think that my current understanding is sufficient for me to begin putting my thoughts in written form. By the way, there are plenty of books on SuperCollider out there, so check them out if you're looking for some actual study material¹.

SuperCollider is at least a couple of things. For one, it encompasses a sound server, which deals with abstractions such as waveforms, signals, events, timing and so on and so forth. I very much suspect that some of its real-time functionality can be overloaded for other applications, but by and large, the point of this server is to interface at the lower layers of abstraction, on top of the system sound providers, e.g. ALSA or whatever. As for the other, the sound server exposes an interface through a protocol called Open Sound Control, or OSC² for short. This protocol is driven by the user-facing component, an interpreter which translates text-form structured input -- in other words, computer programs -- into server commands.

At its core, this looks very much like an evolved form of the C64 programming environment. SCLang is in fact a general-purpose multi-paradigm language, but fit for the particular scope of sound design and music composition, much like what R is for statistical programming or what MatLab is for mathematical modelling. This is a complete departure from the rigid form of traditional "industry standard" DAWs, at the cost of time spent building custom abstractions. So just as is the case for the C64 and SID, the distinction between code and data is thin -- functions are a first-class citizen, for example -- and it's up to the user to draw the lines as he sees fit.

I'd even go as far as to say that SCLang is in fact made up of two almost distinct languages. Take for example the following (somewhat convoluted) snippet:

(
{
    x = SinOsc.kr(2, mul: pi);
    y = SinOsc.ar(440, x, mul: 0.2) ! 2;
    z = Decay.kr(Impulse.kr(1), 2);
    y * z
}.play;
)

Let's unpack this from the top down:

• the parentheses mark a block of multiline code that can be evaluated; this is a stylistic gimmick: had I written the entire expression on a single line, they would have been unnecessary;
• the curly braces denote a function definition, and whatever goes between them is the function body;
• indeed, the user can "play" a function, i.e. instruct the server to play back the signals that were defined as a result of function evaluation;
• the function body contains four statements, separated by semicolons; this syntax has more or less the same meaning as in the C family of languages, i.e. the statements are evaluated in a sequential fashion, from the perspective of the interpreter;
• the last statement bears the special role of a return value; assuming that this return value is a UGen (see below), then the server uses it to generate an audio signal;
• a "unit generator", or UGen, is an object that describes a digital sound signal in the sense of a data flow, i.e. UGens are composable and it's the relationship between them that describes the sound generation and processing path, not the sequentiality of interpreter evaluation; notice for example that the variable x is defined in the first statement and used in the second: this signal flow will be processed in real time when the sound is played back;
• SinOsc and Decay are both UGens;
• there is a clear distinction between "control" and "audio" rate processing³, as observed from the kr and ar specifiers;
• the first UGen, labeled x, is a control rate sine signal running at 2 Hz; the amplitude of this signal -- labeled mul only because in the SuperCollider universe, amplitude modulation and multiplication are the same operation -- is set to pi;
• the second UGen, labeled y, is also a sine, but running at audio rate at the very arbitrary frequency of 440 Hz; the phase of this sine signal is modulated using x; its amplitude is 0.2⁴; the ! is a sugary operator that distributes the same signal over multiple audio channels (in our case, two);
• the third UGen, z, is a decaying envelope running at control rate; this decay signal is excited using an Impulse UGen running at 1 Hz; the decay time (to 60 dB, as per the spec) is 2 seconds;
• the y and z signals are multiplied, which in this case means that y is modulated in amplitude by z; the result is returned; and finally,
• when play is called, the interpreter instructs the server to swallow a compiled form of the resulting UGen, and to feed it as a waveform to the computer's DSP; the resulting sound is an A4 note playing once per second, each note fading in 2 seconds.

Compare and contrast to this more complex -- yet nowhere near the upper boundaries of the system -- example:

(
Task(
    func: {{
        var freq = 440.rand + 440;
        var synth = Synth(\default, [\freq, freq]);
        0.5.yield;
        synth.set(\gate, 0);
    }.loop },
    clock: TempoClock.new(160 / 60);
).play;
)

Similarly, let's try to understand this piece by piece:

• at the upper layer, we have something called a Task; in short, a Task is an object that can be used to schedule high-level "events"⁵ in a timely fashion;
• the Task is instantiated with two arguments: a function and a clock;
• in this particular case, the clock is used to provide tempo control; a TempoClock object is instantiated, running at 160 BPM (160 / 60 beats per second);
• the interaction between the clock and the function is determined by this conversion from beats to seconds; within the function, time is expressed in beats, and its conversion to seconds depends on the tempo (see below);
• at the top level, the function contains an infinite loop, i.e. it wraps another function which is called using the loop method, thus the inner function will be called ad infinitum (or until playback is stopped);
• the body of the infinite loop is similar to the function in the previous example, in that it is used to communicate with the server; but this communication is achieved through higher-level constructs, more precisely through Synth objects;
• in the first statement, a random frequency is randomly chosen in the 440-880 Hz interval, i.e. A4-A5 octave
• in the second statement, a Synth object is instantiated, i.e. as a result, a sound is be played by the server;
• the so-called "instrument" associated with this Synth instance is a UGen wrapped in a standard high-level object called a SynthDef, which provides a convenient way to reuse sounds and to control when they start/stop; for the sake of brevity, the default⁶ SynthDef is used;
• the \freq parameter of the synth instance is set to the previously-defined random frequency⁷; it's expected that the frequency of this default oscillator is set to the same value when the sound is produced;
• in the third statement, the method yield is invoked on the number 0.5⁸; this is to be interpreted as such: the function invocation performs a coroutine-style control flow transfer for a time of 0.5 beats; as this method is called, an internal conversion from beats to seconds is performed based on the tempo clock -- 0.5 * 160 / 60 is about 1.33 seconds -- and as a result the function will pause for this period of time; then, control flow is transferred back to the function;
• in the fourth statement, the set method is called on the synth object; this sets the \gate parameter of the synth to 0, which causes the synth to be released; thus, to summarize:
• this Task schedules a background thread which fires a synth sound of a random pitch between 440 and 880 Hz, each half a beat at 160 BPM.

Both examples are self-contained, so paste them into the SuperCollider IDE and evaluate them to hear the result.

Anyway, at this second point we're no longer in the "dataflow programming world", but we've somehow crossed into asynchronous programming, which is quite important when one wants to program any kind of polyphony into his song. This goes further into loops, quantization and, finally, towards live coding techniques which I won't explore here⁹. Eli Fieldsteel has published a bunch of recordings of his courses which go into much more depth over the course of a university semester.

As for myself, I'm just a beginner who has (so far) composed a few simple songs. I'm not very familiar with either the domain-specific craft nor with the programming style. As usual in programming, everything seems possible if you pour enough work into building the right abstractions, but the jump in complexity from function A to functions A+B is linear only very rarely, assuming, say, the naïve lines-of-code measure. For example, once you near the modest 500 LoC mark, you really need to know what you're doing, otherwise debugging your musical programs is going to be one hell of a nightmare. But if you know what you're doing, then the same level of information density as what went into those beautiful C64 soundtracks, can also be achieved here.

By the way, there's a public code repository available, go check it out.

Filed under: computing.
RSS 2.0 feed. Comment. Send trackback.