Super Collision At Studio Dave: The New World of SuperCollider3, Part 1


SuperCollider is composer/programmer James McCartney's gift to the world of open-source audio synthesis/composition environments. In its current manifestation, SuperCollider3 includes capabilities for a wide variety of sound synthesis and signal processing methods, cross-platform integrated GUI components for designing interfaces for interactive performance, support for remote control by various external devices, and a rich set of tools for algorithmic music and sound composition. And yes, there's more, much more.

This 3-part article combines a preview of SuperCollider 3.5 and a review of The SuperCollider Book, the latest audio-related tome from the press at MIT. I'll introduce the system and some of its components, with example code and screenshots (I love screenshots), then I'll be your tour guide to some interesting SuperCollider projects and Web sites. I'll conclude with a summary of my impressions of SuperCollider, followed by my review of The SuperCollider Book.

Background Bits

In 1996, SuperCollider was released as a closed-source commercial program available only for the Macintosh computer. In 2002 the source code was released to the public under the GPL. Since then development has been consistent and impressive, and the system is now available for Linux, Mac OSX, and Windows, with a high level of cross-platform compatibility.

SuperCollider has been designed as a client/server arrangement, with a clean division between its audio processing parts (scsynth) and the language used to control those parts (sclang). In a typical application the synthesizer is started in a separate process, then the user writes code in a text editor (e.g. Emacs, Gedit, vi/vim) configured for operation with SuperCollider. The editor configuration usually includes mechanisms for controlling the server state and for sending code to the synthesizer for rendering, often as a realtime process.

A complete list of SuperCollider's capabilities would be beyond the scope of this article. Synthesis primitives are well-represented by a variety of oscillators, filters, effects, and control mechanisms (envelopes, gates, triggers). SuperCollider has borrowed the unit generator concept - i.e. an audio processing "black box" - from the MusicN languages. Users combine unit generators to roll their own synthesis and processing graphs into what SuperCollider calls a SynthDef. Many predefined SynthDefs are available, and it's easy to create your own.

The control language includes an impressive number of components for controlling scsynth's output. SuperCollider has great appeal fo improvisors and other realtime-based artists, perhaps because of its wealth of scheduling tools, flow controls, and timepieces (clocks). Some performers use SuperCollider's built-in graphics capabilities to design GUIs specific to their projects in which the UI is the main control panel for the artist's selected processes. Others skip the GUI altogether. I'll have more to say about SuperCollider's interface possibilities, but for now let's move on to the details of installing the system.

Installation And Configuration

The easiest way to install SuperCollider3 is through your distribution's package manager. Failing that nice and easy method you'll have to visit the Downloads page at the SuperCollider site on SourceForge. If no pre-packaged version is available for your distribution you can download a source tarball for the current release. Unzip the tarball in your ~/src directory and follow the instructions for building and installing the program.

If you just want to test drive SuperCollider you can download Puredyne, a Linux distribution with a "live" mode (i.e. you don't need to install it to run it) optimized for media performance. Puredyne includes SuperCollider in its applications stack, along with other excellent Linux audio software, all of which can be installed along with the system if you choose to make it a permanent resident on your hard-disk.

By the way, as of version 3.4 SuperCollider can be built for 64-bit systems. Past versions were limited to 32-bit environments or a 32-bit chroot in a native 64-bit build. If that limitation held you back from getting into SuperCollider, wait no longer.

If you like to test the latest versions of things you can build the SourceForge repository sources. Get the Git software, then open a terminal window, move to your $HOME/src directory, and issue this command :

    git clone --recursive git://

After downloading the code enter your newly-created ~/src/supercollider directory and read the README LINUX file in ~/src/supercollider/platforms/ for the most current instructions for installing and configuring SuperCollider. Now issue these mystic incantations at the terminal prompt (in ~/src/supercollider) :

    mkdir build
    cd build
    cmake ..
    sudo make install

That's all you need for building and installing your own SuperCollider3. You'll probably want to install the standard set of plugins (sc3-plugins) and possibly some Quarks. I'll have more to say about those add-ons, but for now let's continue with our installation notes.

If you'd like to stay on top of SuperCollider's development track you'll appreciate the simplicity of Git's update process. Open a terminal window, enter your ~/src/supercollider directory and run these commands :

    git pull
    git submodule update

The second command is especially important to the build of supernova, Tim Blechmann's multicore-capable replacement for the venerable scsynth. Supernova is built and installed by default with the Git sources, and at some point in the near future it's likely that supernova will replace scsynth. However, at the time of my research a typical installation still deploys scsynth as its default server.

Development is rapid in the SuperCollider world, so I update almost every day. The Git sources are usually stable, but unusual things can and do happen. If you need the most performance-reliable version you should use the official tarball or packaged binary. If you want to know where SuperCollider is headed - and assuming you're not doing critical work - then you'll want to build the Git sources.

By the way, the test platform for the code in this article was Ubuntu 10.04, running in 32-bit mode on a Hewlett-Packard G60 dual-core laptop and a desktop machine built around an AMD 3800+ CPU. Audio hardware included the laptop's built-in soundchip - the ubiquitous Intel HDA chipset - and an M-Audio Delta 66 connected to the desktop iron. Both machines ran the same kernel (2.6.31 patched for realtime operation), the same ALSA system (1.0.20), and the same version of JACK1 (0.120.1).

Running SuperCollider3

As I stated earlier, SuperCollider is designed as a client/server system, so you'll need to start the scsynth audio server before any clients can access its services. A basic invocation looks like this line :

    scsynth -u 57110

This command starts the server with a UDP address of 57110. The address is needed to provide a port for OSC communications with sclang, the SuperCollider language front-end. You can automate your server configuration and other start-up details through ~/, a small configuration file for launching SuperCollider with your specified defaults. Here's the config at Studio Dave :

    // Where's the server ?
    Server.program = "/usr/local/bin/scsynth";

    // Set up server for available audio I/O channels.
    #[\internal, \local].do { |s|
    s = Server.perform(s);
    s.options.numInputBusChannels = 2;
    s.options.numOutputBusChannels = 2;

    // Connect JACK ports to audio channels.

    // Where's the SwingOSC GUI server ?
    SwingOSC.program = "/home/dlphilp/jars/SwingOSC.jar";

As you can see, this file lets you determine some options for connecting to JACK. The example is restricted to the simple 2-channel capabilities of my laptop, but it can be expanded to accommodate however many connections your hardware supports.

The configuration file doesn't actually start the server. You can start it manually from a terminal prompt as shown above or from a text editor configured for working with SuperCollider. SuperCollider can be operated from the command line, but it is typically launched and operated from within a text editor configured to provide access to the system and its resources. The editor will also provide amenities for highlighting and evaluating (i.e. running) your code, starting and stopping the audio and graphics servers, accessing the Help documentation, and so forth.

Sclang, SuperCollider's control language, is based on Smalltalk, an object-oriented programming language. Beginners should find no special difficulty understanding SuperCollider's semantics and coding syntax; however, if you're coming from an environment such as Csound or Pd you may find that you may need some background in the basics of the object-oriented method. Alas, this article is hardly the place for an extensive description of object-oriented programming, so I'll redirect readers to the Wikipedia page on the topic.

You'll use sclang's language elements when you write a SuperCollider program in your correctly configured editor. As I said, it may be possible to write SuperCollider programs from the command line, but it will certainly be easier for beginners to use sclang with an editor. Later in this article we'll look at some example code, all of which is written and executed within my text-editor of choice.

Incidentally, sclang is not the only client-side language for the scsynth audio server. The server is basically a responder to properly configured OSC messages, and alternative clients have been created for the Haskell and Scheme programming languages. Those clients bypass sclang entirely, replacing its syntax and language elements with those of the client.

We must move on, but of course there's much more to scysnth/sclang than I've introduced here. The Wikipedia page on SuperCollider has a good concise description of scsynth and sclang, so rather than repeat that material I'll direct readers to the page for more details regarding SuperCollider's client/server model.

Configuring The Editor, Ubuntu-style

The following instructions apply only to the Gedit text editor running on an Ubuntu system. Emacs and vi/vim users should configure their editors in a similar manner. See the SuperCollider web site for instructions on configuring your favorite editor.

To configure Gedit for SuperCollider support start the editor, open the Edit/Preferences dialog, and select the Plugins tab. You should find a plugin named Sced, the SuperCollider editor. Activate it, close the dialog, and you should have a SuperCollider Mode item in your Gedit Tools menu.

By the way, if you're building from the source code and you don't find the Sced plugin after installing SuperCollider just step through these copy routines to prepare Gedit :

    cp ~/src/supercollider/editors/sced/sced/ ~/.gnome2/gedit/plugins/sced/
    cp ~/src/supercollider/editors/sced/data/sced.gedit-plugin ~/.gnome2/gedit/plugins/sced.gedit-plugin

Restart Gedit and the plugin should be available for installation as described above.

You're almost ready to roll. You'll still need to install the SwingOSC package if you want the Java-based Swing GUI components, and you'll eventually want the sc3-plugins and some SuperCollider quarks (i.e. specialized packages that typically include class code with examples, help, and other support files). See the SuperCollider SourceForge site for up-to-date information regarding those downloads.

By the way, you need the SwingOSC package for only one file found at /path/to/SwingOSC/build/SwingOSC.jar. Copy this jar file to a permanent location, then specify that location in your ~/ file :

    // Prepare SwingOSC
    SwingOSC.program = "/home/dlphilp/jars/SwingOSC.jar";

I use Gedit's SuperCollider menu options to operate the SwingOSC server and to launch a panel for controlling scsynth, SuperCollider's audio server.

Okay, let's take a moment to review. The system is installed, your file has been duly customized, your favorite text editor is prepared and ready for action - I'd say it's time to run some code.

Super Simple

If you've never seen or heard code from SuperCollider I've prepared an example with some basic operations, including the addition of a GUI. I describe the process in the context of Gedit, but the unaltered code should run in Emacs or vi/vim.

So, I open Gedit, activate its SuperCollider mode, and start the server from the SuperCollider menu. I open a new document, set its Highlight Mode to the SuperCollider language, and enter the following code into it :

    a = {}.play;

To the right of the = sign this line presents the invocation of a sine wave oscillator with some value to be passed to it, a frequency value in this instance. The .ar extension lets SuperCollider know that the output is an audio-rate signal, and the .play command extension tells the system to render the sinewave to audio output in realtime. The whole thing is assigned by that = sign to a variable named a.

Incidentally, SuperCollider code is read and evaluated from left to right. Normal math precedence does not apply, so if your code includes this sort of line :

    n = 5 + 4 * 3

the answer will be 27, not 17. For the latter result the code needs rewritten to force precedence :

    n = 5 + (4 * 3)

Let's return to our example. I can turn off the audio output with the Stop Sound item from Gedit's SuperCollider menu, but I'll add this line for a handy off-switch within my code :;

To evaluate the first line I select the text then press Ctrl-E or choose the Evaluate item from Gedit's SuperCollider menu. If the evaluation succeeds I hear a sine wave with a frequency of 440 cycles per second. I evaluate the next line the same way to turn off the sound, and huzzah, I'm on my way to SuperCollider mastery. Figure 1 shows off this little session in Gedit.

Figure 1. SuperCollider3 in Gedit (Full-size)

If the evaluation is unsuccessful the SuperCollider log window will print an error message that should indicate the source of the problem. SuperCollider's error reports are often detailed and utterly confusing to the novice, so you'll want to spend some time learning how to read them. The documentation includes material on troubleshooting, and most problems can be resolved by a careful investigation of the reports.

Outro, Part 1

Parting is sorrowful, but I'll be back in a week or so with the continuation of this series. I hope you'll take some time between now and then to look into SuperCollider3, maybe even check out the examples here and in the system documentation. In the next part we'll look into its GUI capabilities, its MIDI possibilities, and we'll even get a brief glimpse of its power as an environment for algorithmic composition. Cool stuff, don't miss it. 

Load Disqus comments