Day One of 30 Days of Supercollider

Years ago when Flash was on its way out, I started looking more and more into JavaScript and HTML’s Canvas as a replacement. I started a series on my earlier blog called 30 days of JavaScript. It was popular and moreover I learned a lot, needing to learn some new aspect of the language and graphics api each day.

Now that I’m taking a deep dive into Supercollider, I decided to try that same trick again. So, I plan to make 30 posts in the next 30 days (bear with me if I miss a few days here and there) tackling some aspect of Supercollider.

Caveat: these won’t be super in-depth most likely. Some of them will seem very basic and naive to anyone who knows this stuff more than I do. I can’t even guarantee that everything I write will be correct. But, as a wise person once said (paraphrased), the best way to learn the correct way to do something is to post the wrong way; someone will instantly show up to correct you. 🙂

Supercollider IDE

So let’s dive right in. Supercollider is actually a suite of several bits of technology that come together to form an environment for programming, playing, and recording synthesized sounds and music.

The parts are:

• The Supercollider language, called sclang. There will probably be many posts on the language itself, as it’s quite different from most languages I’ve worked in, and I suspect it will be the same for other programmers out there.
• The Supercollider interpreter. This is what reads the sclang code that you write, interprets it and sends it to …
• The Supercollider server. Known as scsynth. This receives the interpreted commands from the interpreter and translates it into sound and music. And other things that aren’t necessarily audible, like timings, routings, etc.
• The Supercollider IDE. This is scide. And is what we’ll be covering lightly today.

Here’s what the IDE looks like currently on my Linux laptop:

Pretty standard stuff here. On the left is a place to write your code and on the right you have some docks – the Help Browser and Post Window. The Post Window shows the output of the commands you run, success, errors, other messages. You can also log your own messages here, which about as much debugging capability as you’ll get here.

The editor is decent. It has color coding with different available color schemes. I found and installed a gruvbox theme, which makes me feel at home (code and instructions here: https://github.com/brunoro/base16-scide). It has pretty good code completion and hints for method parameters. You can do Ctrl-D or Cmd-D on a keyword and see the documentation for that item in the Help Browser.

On the bottom right is a status bar that shows what’s going on with the interpreter and server. When everything is green there, you know the server and interpreter are running and ready to convert your code into music… or something noisy anyway.

There are also a number of helper panels you can open up to visualize what’s actually going on with your compositions.

Seen here are the Node Tree, which shows the active objects, the Server Meter, showing the input/output levels across channels, the Stethoscope showing a wave form for any channels you choose, and the Frequency Analyzer. The last is particularly useful for seeing visually what different filters are doing to your sound.

One thing that took a lot to get used to is the way that Supercollider interprets the code you write. In every other language I’ve ever worked in, you write code in a file and save and do something that builds that code – either interpreting or compiling that code, possibly importing and/or linking other code files in with it and then executing the result.

This is not even remotely how Supercollider works. Part of the reason for this is that Supercollider was originally conceived of as a tool for musical performance. So you wouldn’t be just sitting down and spending a long time creating this perfect program and then running it. Instead, you’d code a little bit, run that, add a bit here, run that. Stop that bit, change it a little and re-run it. Then code a few more pieces and add them to the mix, maybe removing some of the earlier bits as you go.

So generally, the way things work is you’re evaluating one specific block of code at a time. This can be a single line by default, or you can select multiple lines, or even a portion of a line and evaluate that. Whatever you evaluate gets instantly interpreted and sent to the server and if that code creates a sound, you’ll hear that sound.

The most common shortcut you’ll use is Ctrl-Enter or Cmd-Enter on Mac. This evaluates what’s under the cursor. If nothing is selected, it will evaluate that whole line. If a part of a line or multiple lines are selected, it will evaluate the entire selection.

But say you have some code like this:

var freq;
freq = 300;
{ SinOsc.ar(freq) }.play;

In order for anything meaningful to happen, you need to select all three lines and then evaluate them. And that’s a very minor example. As you can imagine, you might have a chunk of code that is dozens of lines long that needs to all be evaluated together. For this, we have regions. Creating a region just means putting a pair of parentheses around the code you want to be evaluated as one large unit. Like so:

(
var freq;
freq = 300;
{ SinOsc.ar(freq) }.play;
)

Now you can put your cursor anywhere inside the parentheses, or even on one of the lines with a parentheses, and hit your shortcut and the whole thing will be evaluated and sent to the server. Also, if you are in a region, but only want to evaluate a single line of code, you can hit Shift-Enter and only that current line will be evaluated.

There’s also a menu item to evaluate the whole file, but there’s no shortcut by default for that. Coming from other “normal” programming languages, that seemed absurd to me and I immediately set up a shortcut for that. Eventually I figured out that you almost never want to evaluate a whole file and removed that shortcut.

The other important (very important) shortcut is Ctrl-. or Cmd-. (Control or Command + the period key). This stops all sounds from playing. You’ll work that into muscle memory quickly, especially after having a few random and unexpectedly loud noises blasting in your headphones.

Linux Audio

Just a note for you Linux nerds like me. The first week or so using Supercollider, I had to do it on my Macbook Air because the Supercollider server would not start on Linux. I knew I could fix it, but wanted to focus on learning a bit more about Supercollider itself before delving into Linux audio configuration. Eventually though, I put in the effort to figure it out.

The problem is that on Linux, Supercollider needs to use the Jack audio system. But most Linux systems right now use PulseAudio. Both of these interface to your sound card using ALSA. Jack is apparently superior and used by most serious audio software on Linux, but for some reason is not the default.

I was able to get Jack started by installing QjackCtl which gives you a nice little panel to turn Jack on and off. That got Supercollider working just fine, but it killed everything else that was running via PulseAudio on my computer. Once I turned Jack off, PulseAudo and the rest of my apps worked, but they were mutually exclusive. I finally found the solution here:

https://wiki.archlinux.org/title/PulseAudio/Examples#PulseAudio_through_JACK

This was a little fiddly and took a couple of reboots. Possibly because Jack was still running in the background via QjackCtl. But once it started working it was fine. I just open up the Cadence app and start Jack. Now all my computer’s audio is routed through Jack and everything works as expected, including Supercollider. If I turn Jack off, everything reverts to using PulseAudio instantaneously. So I’m very happy with that. Since I’m messing with Supercollider on a regular basis, I tend to just leave Jack running all the time now.

[Update] – already had a comment on Jack vs PulseAudio that Pipewire should resolve a lot of this. I checked and I do have PipeWire installed on my system, but it doesn’t seem to be in use. I’ll be digging into this more and will update with any fun findings.

Summary

So there’s Day One. Not too exciting, but I’ll be prepping a list of other topics and as I go I will create an index to all the articles. Hopefully some of them will be useful, if not to you, at least to me.