Advanced Use

The examples in the previous parts of this series should be fairly intelligible to someone with a background in Csound or a similar MusicN-derived language. They demonstrate a few basic principles of SuperCollider's linguistic elements, but they miss most of what's most interesting about the environment. In fact, SuperCollider's debt to the MusicN heritage is relatively small, and its design considerations have been differently ordered. From its inception SuperCollider has favored realtime operations in an interactive environment. On the server side the design has nurtured a high-performance audio synthesis/processing engine. On the client side the control language has developed many elements either not clearly defined or not present in other computer music systems. An in-depth presentation is not possible in this article, but we can catch a glimpse of some of SuperCollider's more advanced features.

Of Tasks, Routines, Patterns, And Streams

We've already met a Task in our prettified example of a synth-plus-GUI. Tasks and Routines are closely related mechanisms often found working together in SuperCollider code. A Routine is a function with stop/resume capability, while a Task is a process with similar charactistics, i.e. it is a pausable process. Our synth GUI example in Part 2 showed off a typical combination of Routine and Task, the SuperCollider documentation includes many others.

Routines are also closely related to Patterns. Musicians are accustomed to the term "pattern", but it means something unique in SuperCollider, where a Pattern is

"... an object that responds to asStream and embedInStream. A Pattern defines the behavior of a Stream and creates such streams in response to the messages asStream. The difference between a Pattern and a Stream is similar to the difference between a score and a performance of that score or a class and an instance of that class. All objects respond to this interface, most by returning themselves. So most objects are patterns that define streams that are an infinite sequence of the object and embed as singleton streams of that object returned once."

To the typical musician that explanation is probably about as clear as mud. Have no fear, illustrative examples abound in the SuperCollider documentation and elsewhere, but before we display one let's find out what's a Stream in SuperCollider-speak. The docs say this about it :

"A Stream is an object that responds to next, reset, and embedInStream. Streams represent sequences of values that are obtained one at a time by with message next. A reset message will cause the stream to restart (many but not all streams actually repeat themselves). If a stream runs out of values it returns nil in response to next. The message embedInStream allows a stream definition to allow another stream to "take over control" of the stream. All objects respond to next and reset, most by returning themselves in response to next. Thus, the number 7 defines a Stream that produces an infinite sequence of 7's. Most objects respond to embedInStream with a singleton Stream that returns the object once."

In another section of the documentation we learn that Stream is "an abstract class that is not called directly". Okay, so now that all that's been explained we need to explain these explanations. In other words, we need some examples to clarify this business. Fortunately there are plenty of helpful examples in the SC documentation, so let's look at one :

    // Here Pbind folds a Prand pattern into a stream playable by the default synth.
    Pbind(\freq, Prand([300, 500, 231.2, 399.2], inf), \dur, 0.1).play;

You may have already figured out that classes that begin with P are variants (extensions) of the basic Pattern model. Thus we have Pseq, Pbind, Prand, Pfunc, and many other Pattern types, all with detailed descriptions in the docs. The simple code above demonstrates some of Pattern's power - on evaluation an infinitely repeating series of tones are played in random order by the default synth with the frequencies specified in the Prand array and with the fixed duration specified by the (\dur, 0.1) pair. It takes little reflection to see the potential of the Pattern class, and a little study of its documentation opens doors to all kinds of interesting devices for composition and manipulation.

A Pattern can be considered as a collection of events - pitches, soundfiles, images - that gets converted to a Stream. A musical example would create a Stream of duration values or pitches that gets fed to a synthesizer or other processor. A Pattern can include other Patterns within itself, Patterns can be replaced by other Patterns in realtime, or multiple patterns can be played in syncronized or unsync'd playback, as the following example demonstrates :

    (
      // Declare two variables for the Pbinds.
    var a, b;
      // Create two pattern streams with defined pitch and duration values.
    a = Pbind(\freq, Pseq([470, 440, 400], 4), \dur, Pseq([1, 0.5, 1.5], inf));
    b = Pbind(\freq, Pseq([200, 220, 240], 4), \dur, 1);
      // Perform the streams in parallel.
    Ppar([a, b]).play;
    )

The pitches in the Pseq arrays are represented here as frequencies in Hertz, one of many possible representations for pitch classes in SC. The "4" after the freq/Pseq pair indicates the number of times the sequence will be repeated.

New users who want more information about Patterns and Streams should read the on-line Help tutorial titled Understanding Streams, Patterns, And Events. You may find the documentation's text explanations somewhat puzzling, in which case you must be sure to run the examples. I've found that my confusion is often removed by going through the excellent examples - the SuperCollider docs include some great demonstrations - that clarify what a class or object actually does in a musical context.

Sounding Out

For me, the proof of the system is revealed in the possibilities of its logic and the quality of its audio output. I've only begun to explore SuperCollider as a system for algorithmic composition, so I'll have to wait for my investigations to bear satisfactory results before I venture an opinion regarding the system's strengths in that domain. [Note 8/31: No doubt about it, the system rocks for my purposes.] However, regarding SuperCollider's audio quality, there is no doubt: My ears are impressed. Subjectively I compare SuperCollider's audio output to my experience and satisfaction with Csound's audio quality, and what I've heard so far hasn't suffered by the comparison at all. I've already mentioned the quality of the many fine examples in the documentation, the following links point to sites that contain music and sound pieces by composers using SuperCollider :

  The SuperCollider Group On Soundcloud
  Recent And Selected Works by Josh Parmenter
  Instrumental Works & Scores by Andrea Valle
  Works In SuperCollider by James Harkins
  SuperCollider On The Internet Archive
  SuperCollider3 On YouTube
  SuperCollider Groups On Vimeo
  Rick T's YouTube tutorials (highly recommended for new users)

I believe that SuperCollider - like any other music/sound programming environment - is ultimately best advertised by the works created by its users. The given links are a small taste of what I've found on the Web, but they indicate clearly that SuperCollider is capable of handling any style or form of musical statement, from the rigidily deterministic and non-realtime all the way to the most unrestrained realtime improvisations.

Super Softs: Friends Of SuperCollider

Earlier in this article I mentioned that there's no general-purpose front-end for SuperCollider, not in the same sense that QuteCsound is such a front-end for Csound. However, SuperCollider enjoys the company of some unique software helpmates.

SuperCollider can capture and process input data in a variety of formats, including MIDI and OSC. The system's MIDI support is excellent, and there should be no special difficulty in connecting the system to your MIDI hardware and favorite software. If OSC is your preferred protocol you have at least three OSC sequencers to consider. I've already reported some news regarding IanniX, CM/Grace, and AlgoScore in previous articles about OSC. The first two programs have seen significant upgrades since then, and AlgoScore's author intends to replace that software with something more SuperCollider-savvy.
 

Figure 1. IanniX (Full-size)

IanniX is an OSC message sequencer with a unique user interface (Figure 1). It's a perfect candidate for a connection to SuperCollider, and the latest release is a great advance over the last version I reviewed. The new version includes some interesting example files for setting up SuperCollider for control via IanniX (and vice versa). Recent releases of Rick Taube's CM/Grace system includes some Scheme examples for connecting the powers of Common Music to those of SuperColllider. Grace is an environment for composition - it's not an audio synthesis system, its output capabilities rely instead on external systems such as Common Lisp Music, Csound, and now SuperCollider. Jonatan Liljedahl's AlgoScore is no longer maintained, but its last release is perfectly capable of sequencing OSC and/or MIDI messages to SuperCollider (see my article on AlgoScore for more information). Jonatan is now active in SuperCollider development, and he has indicated that an AlgoScore2 might happen, with a particular focus on its acquaintance with SuperCollider, of course.
 

Figure 2. FScape and Eisenkraut (Full-size)

Hanns Holger Rutz is a composer and developer extraordinaire for SuperCollider, Pd, and Csound. Among his contributions we find the SwingOSC graphics server, the FScape audio processing modules, and Eisenkraut, a soundfile editor that requires SuperCollider for its audio processing engine. FScape and Eisenkraut both respond to control messages coming from SuperCollider (see Figure 2), allowing the user to run FScape processing modules from within SuperCollider, add new menu items to Eisenkraut's GUI, apply external DSP routines on soundfiles, and perform other actions through SuperCollider's vast powers.

Figure 3. Meloncilllo (Full-size)

Herr Rutz is also responsible for Meloncillo (Figure 3), a utility for the spatialization features of SuperCollider3 and Csound5. Arcs of travel for your sound sources are plotted in a Java-based GUI, then sent to the receiving program. Alas, the latest public release didn't work for my build of SuperCollider 3.5, but all problems appear to be resolved in Meloncillo's latest SVN sources. It's now playing nicely with SuperCollider - in realtime too - and it looks especially useful for designing complex sonic trajectories for multiple speaker arrays. Definitely a cool tool.
 

Figure 4. Processing and SuperCollider (Full-size)

Processing users can access many SuperCollider functions in their sketches through the p5_sc library. A Google search discovered a few other means of access, but the p5_sc library is a good starting point for weaving together Processing's graphics capabilities with SuperCollider's audio powers. Incidentally, SuperCollider has some interesting graphics possibilities of its own, but you'll have to look into the documentation for more information regarding those capabilities. (Hint: Check the documentation for the Canvas3D class). Interested users should also look at Julian Rohrhuber's OpenObject system (Figure 4) and its external control possibilities for SuperCollider, including the use of Processing and Pd as controlling GUIs.
 

Figure 5. MEAPsoft (Full-size)

MEAPSoft is an audio slicer/chunker with a Java-based GUI (Figure 5) and a set of classes and help files for using its data within SuperCollider. The main program is run outside of SuperCollider - it performs the sonic manipulations on your audiofile and creates an EDL (edit decision list) and other data lists that can be imported into SuperCollider. Once the lists have entered SuperCollider's world they can be subjected to SuperCollider's great variety of DSP functions and other routines. Alas, I was unsuccessful in my experiments with manipulating the data produced by MEAPsoft 2.0.4b in SuperCollider 3.5, but the program itself works perfectly on its own. Data files produced by the earlier 1.1.1 release work fine with the SuperCollider class.

Wii devices, Androids and iPhones, tablet controllers, Arduino boards, motion trackers, proximity and heat sensors, Webcams and other video devices, the variety of MIDI hardware - SuperCollider works well and plays nicely with everyone. Its users include DJs/VJs, movement artists, improvising musicians and poets, live coders, and every possible blend of the above. SuperCollider also provides spatialization features for massively multiple speaker arrays and multi-dimensional audio formats. Alas, I haven't the hardware necessary to explore those features, but readers can look into the relevant material in the SuperCollider Book for more information.

Documentation

There's an abundance of documentation in the on-line Help files, and now we have The SuperCollider Book. The program Help is generally excellent - I'll mention the outstanding examples again - but alas, many classes are undocumented. As with all things SuperCollider, its documentation is an on-going project, and users are encouraged to assist.

Mistakes will be made, so you'll need to acquaint yourself with SuperCollider's Help system and its error reporting. If you're truly stuck at some point you can usually find the knowledge you need on the SuperCollider users mail list. A developers list is also available, though I suggest that new users restrict their activity to the users list. Discussions on both lists are typically more technical than musical in nature, but new users should feel free to ask about any points of confusion. Many developers are also notable users, and there are many friendly folk who will try to get you to the help you need. The SuperCollider home page points to the excellent wiki and other relevant sites, and of course, as in so many ways, Google is your friend when you want to sift through the SuperCollider-related material out there on the net.

Evaluations

I see no reason why SuperCollider would pose any extraordinary difficulties for an interested novice with no previous conceptions regarding an audio programming language. The basics of the language are not terribly difficult to learn and helpful example code abounds. Indeed, I've often found the best documentation to be the programs themselves. SuperCollider comes with example code that includes complete pieces as well as tutorial and other instructional material. With those items, the existing Help docs, and the SuperCollider Book you should be in excellent condition for starting out and advancing on the SuperCollider Way.

As a long-time Csound user I can't help but compare that wonderful environment and the world of SuperCollider. However, their primary design considerations differ so greatly that any comparison is bound to be superficial and unsatisfactory to dedicated users of either system. It's fair to acknowledge that SuperCollider fits into realtime use cases with greater flexibility than Csound, but it's also worth pointing out that some Csounders also work mainly in realtime performance, and some SuperCollider users employ their system for non-realtime composition and off-line rendering.

Csound also carries a lot of legacy - it derives from the MusicN systems defined by the late Max Mathews - and some users find its syntax archaic enough to force them to look for ways to work around its shortfalls, e.g. using Python or Java front-ends for instrument design and score production. The language is not designed after a contemporary model, but it is quite easy to learn, thanks to MusicN's design proposition that typical musicians ought to be able to quickly understand and use the system.

SuperCollider's language model is based on a relatively more modern basis (Smalltalk). Like cmusic and RTCmix it presents no necessary distinction between the instrument and score code, i.e. a single code block can contain all needed synthesizer definitions and score directives. Much of SuperCollider's terminology may not be readily apparent to musicians, but a few good examples make it clear that SuperCollider provides a different - and very exciting - way of thinking about how we make music with a computer.

By the way, owners of The SuperCollider Book should read the material in the sections titled Practical Applications and Projects And Perspectives for a broad view of SuperCollider's utility in real-world applications, some of which include complex sound installations with huge multispeaker arrays.

I applaud the designers' decision to employ Qt as a cross-platform GUI toolkit. Yes, some Cocoa components remain missing, and some Swing-based GUIs function better than their Qt equivalents, but the SuperCollider/Qt connection is working nicely and developing rapidly. Special thanks and praise goes to Jakob Leben for his continuing work on SuperCollider's Qt interface. The job is big, behind the scenes, and not really very sexy, but the payoff is terrific at the user level. I've already run some "Cocoa-only" code that was formerly restricted to the Mac's GUI toolkit, and I anticipate the day when anyone can run any SuperCollider code with little or no change, regardless of platform or version.

(I'm also waiting patiently for the IxiQuarks to be available in new Qt GUIs. Hint hint.)

Before leaving I'd like to thank the SuperCollider user and development communities for their help with my various quandaries. Special thanks to Tim Blechmann, James Harkins, Jonatan Liljedal, and Marije A. J. Baalman for their invaluable technical advice and assistance.

Be advised that SuperCollider 3.5 is a work in progress. It represents a great development milestone for the project, with many new features and an optimized codebase. I don't know when 3.5 will become the official release - SuperCollider is an open-source project with distributed development, and my experience with such projects advises me to adopt patience and to provide encouragement and bug reports. Meanwhile, I'm still a beginner, I have a lot to learn, so I'll finally end this report and get back to my classes (hehe). I hope you enjoyed the tour, and I hope also that you've been inspired to try SuperCollider yourself.

Outro

Please see my recent review of The SuperCollider Book. Lots of stuff happening in the Linux audio cosmos, including an upgraded Mixbus 2.0, some new LV2 plugins, Loomer updates, significant development in QTractor, and the list goes on. I'll be back in a couple of weeks, check in to see what I'll bring with me.