Supercollider (downloads link) is the collective noun describing two coupled programming languages oriented toward live interactive music. I used ’em a lot, e.g. for pattern machine,
The default user-facing frontend is a language called
sclang, an ageing smalltalk
derivative with neat scheduling facilities embedded in some awkward
abstractions, and a lot of handmade quirk.
The DSP backend is called
The two talk to one another over a decrepit defunded network protocol from 1999
scsynth is wonderful.
sclang contains some wonderful advanced features,
but is hamstrung by its ancient and unrefactored early design decisions.
It’s an underdeveloped ghetto, kind of a District 9 of software.
The Unique-Selling-Point features are stuff like
supporting polyphony with programming primitives in a natural fashion, and
a more sophisticated time and sequencing system than anything else I’ve seen. (although they still don’t do it quite right; leaky abstractions and poor management of state mean that it’s IMO a glorious failure rather than ultimate sequencer.)
It has a small but committed community, and doesn’t require extortionate licensing fees as an open-source project. Unfortunately it is purely GPL’d, which makes it difficult to release real software using it or put it on iphones etc.
sclang extensively, I feel qualified to recommend against it;
It has fame and regard because it really was the best in the field in 2002;
But it’s missing the bulk of the progress since 2002 that mainstream
languages have taken for granted.
Supercollider’s tasty language features sound great, but they are nearly
unusable because of the obscure and buggy nature of the language they are
Also, it’s falling gradually apart. Supercollider is rootbound by a frozen and confusing chaos of early design decisions that make the sequencing unreliable and inflexible, state-management an irritating hack, and the ecosystem a jungle of different partial workarounds. Modern functional reactive programming has honed a lot of the design patterns, but that revolution kicked off after supercollider’s development decision were more or less fixed.
scsynth instead of
There is a whole ecosystem of alternative languages
that interface with the DSP core, because everyone has had more or less the same opinion regarding
Thus we have
scsynth front-ends for
Ruby (sonic-pi), and
All of these have different pluses and minus.
They each have access to richer ecosystems built around their respective languages, in exchange for worse integration with sclang.
In the classic failure mode of academic publishing, the de facto manual for SC was released as a closed-source, heavily-delayed, pre-obsoleted, expensive book. There is an effort underway to translate Valle’s alternative manual to English.
In the following I mention a few negative, uh, misfeatures. Don’t interpret these mentions as complaints as such; think of them as little public encouragements for me to learn C++ coding and start fixing them. NB: this won’t actually ever happen.
OTOH, why does there exist yet another poorly-maintained programming language, when we have many, many other such? hy not choose your battles by adapting a mainstream language with a maintenance budget to be better at programming audio? If that sounds too tedious (and it is somewhat tedious) here are some things that you be aware of when using supercollider.
No step debugger, so you have to debug your complex nests of client and
server-side code with print statements.
That’s the recommended way, and precisely what the
debug method does.
Get ready for hours reverse engineering your code to work out what this time cause the Omni Error:
^^ The preceding error dump is for ERROR: Message 'foo' not understood. RECEIVER: nil
Used to defining variables in a REPL and then using them later?
Try running these two lines, both at once:
var foo="bar"; foo;
You should get back, as you’d expect,
bar. Now, run them one at a time.
• ERROR: Variable 'foo' not defined. in file 'selected text' line 1 char 3: foo•;
You can work around this by using “environments”,
and other hacks, that is, creating variables
as entries in a hash-table with reasonably compact syntax:
give them names prepended with a tilde, as, e.g.
However, this means that you have different syntax and scoping
rules between live and library coding.
There are more or less two different languages you now have to work with,
and neither helps to debug the other particularly much.
If, say, you wanted to copy a troublesome method
from a class into the interactive document window to step through it and
work out where it’s gone wrong (since, as mentioned above, there is no step
debugger, this is as good as it gets) you also have to change the syntax and will likely interoduce new errors.
And so the pain develops from a nagging irritation to a skull-grinding cluster headache.
While supercollider still has the best sequencer of any language I am aware of,
other concurrency and scheduling problems have been solved
by the rest of the world while
If you code the way that the help files do things, i.e. small numbers of lines of code, each executed manually, you will end up writing code that looks like it works but explodes the moment you try to increase the speed or parallelism with which it is executed. To do anything at all you need to execute it inside a Routine and use server synchronisation to make sure that nothing arrives out of order. However, in my experience this is still not 100% reliable; the entire thing relies on UDP packets which have no particularly useful guarantees about order of arrival or verification of arrival. However, it’s better than nothing; If you don’t do this, sometimes you will get nice, plain errors. More perniciously, sometimes, with patches involving complicated wiring such as Instr and FFTs and such, you put yourself at risk of having things wired together entirely incorrectly, and having hard-to-trace examples of Bus objects full of crosstalk and garbage.
OSC and MIDI are handled by an elegant evented asynchronous callback system after the latest modern style. Could be better but feels fairly natural, and you can subclass away the rough edges. However for all other IO (file, socket, other network protocols, serial, whatever), it’s blocking access. So if you wish to talk other, more modern protocols, you are without hope, and for that matter, your elegant OSC/MIDI system is caught in the crossfire. In practice you end up running another SC instance to relay pipe contents over OSC.
No comments yet. Why not leave one?