The SuperCollider sound server scsynth is one of the most finely tuned and efficient synthesis engines out there. For most people on most modern computers, they will rarely meet limitations in terms of effeciency.
That said, scsynth does have one potential for optimization: Parallelization. And this is where supernova comes into the picture.
The original scsynth sound server in SuperCollider, like lots of other audio software, runs on one core and so your computer’s single core performance is a big limitation for the possibilities of scsynth.
Around 2010-2011, an alternative synthesis server, supernova, was bundled with SuperCollider to solve this problem. You can read the original 2011 paper that introduced supernova here written by the designer of supernova, Tim Blechmann.
supernova is a drop-in replacement for scsynth that supports some tricks for parallelizing synthesis and spreading the load of your sound work over several cores.
I could not find much information on how to make use of the supernova server (which, I found out, is probably because it’s surprisingly simple), and so this is a little write-up on how to make use of it.
Switching the sound server to supernova
The first step in making use of supernova is to switch your sound server from scsynth to supernova. This is done in SuperCollider like this:
Server.supernova;
(You can add this to your startup file if you want to always use supernova)
Then, all you have to do is boot or reboot your server:
s.boot;
Now, notice the post window, it should say something along the lines of “SuperNova booting”.
That’s it, you are now running supernova.
Well, I say “that’s it” - but that’s not the full truth. Even though you are now running supernova you are probably not making use of it. One would be mistaken to think that since we are now magically parallelizing every sound operation in SuperCollider, but that’s not how it works. Instead, to make use of these features you need to explicitly understand and use some objects and concepts that were introduced with supernova.
Parallel groups
When spawning synths in SuperCollider, each synth is represented as a node. All nodes are organized in groups. This is the primary point of parallelism for supernova. With it’s introduction to SuperCollider, a new language side representation of parallelized groups were introduced: ParGroup.
The original paper explains them like this:
“Like groups they can contain child nodes. However, instead of evaluating the child nodes sequentially, the order of execution is undefined, so all nodes can be evaluated in parallel. This provides the user with a simple facility to explicitly specify parallelism”
and:
“Members of parallel groups are synchronized in two directions: they are evaluated after all predecessors of the parallel group have been evaluated and before all successors.”
This means that if a group for example contains a lot of synths that are playing “side-by-side”, for example if each note in a chord are represented by a singular synth node, a ParGroup would be able to parallelize their load on multiple cores. It is not able to parallelize a dependency that goes the other way: From top to bottom.
Here is a simple example of creating a parallel group and playing a bunch of synths inside of it. If you have a system’s resources monitor ( like the htop or btop terminal programs) on your computer, you can open it up and search for supernova and see how it distributes the load.
// Play 10 synths in parallel
(
var group = ParGroup.new();
10.do{ Synth(\default, [\freq, exprand(80,250), \amp, 0.125], target: group) };
)
To do the same thing in an event pattern, you will need to wrap the event pattern in a PparGroup:
// Play 10 synths in parallel in a pattern
(
PparGroup(
Ppar(10.collect{
Pbind(\degree, Pwhite())
})
).play
)
In addition to parallel groups, the original paper describes sattelite nodes that may be using using the .preceding method on a Synth object, but it seems they were never implemented.
For more information or questions regarding supernova, visit the scsynth.org forum