Debugging tips 

Debugging synthdefs 

Debugging client-to-server communication

Debugging client code 

Debugging synthdefs 

The challenge in debugging synthdefs is the invisibility of the server's operations. There are a handful of techniques to expose the output of various UGens. 

SendTrig / OSCresponderNode 

SendTrig is originally intended to send a trigger message back to the client, so the client can take further action on the server. However, it can be used to send any numeric value back to the client, which can then be printed out. 

To print out the values, you need to create an OSCresponderNode as follows:

o = OSCresponderNode(myServer.addr, '/tr', { |time, resp, msg| msg.postln }).add; 

Each line of output is an array with four values: ['/tr', defNode, id (from SendTrig), value (from SendTrig)]. 

{ var freq;

freq =, 600, 800);

// Impulse is needed to trigger the /tr message to be sent, 0, freq);, 0, 0.3) ! 2


[ /tr, 1000, 0, 1340.8098144531 ]

[ /tr, 1000, 0, 1153.9201660156 ]

[ /tr, 1000, 0, 966.35247802734 ]

[ /tr, 1000, 0, 629.31628417969 ]

o.remove;  // when done, you need to clean up the OSCresponderNode

If you need to track multiple values, you can store them in a collection of arrays and differentiate them by assigning different IDs in the SendTrig UGen. 

l = { } ! 2;

o = OSCresponderNode(myServer.addr, '/tr', { |time, resp, msg|

// msg[2] is the index



{ var freq, amp;

freq =, 600, 800);

amp =, 0.5, 0.5);

// Impulse is needed to trigger the /tr message to be sent, 0, freq);, 1, amp);, 0, 0.3) ! 2


o.remove;  // when done, you need to clean up the OSCresponderNode

l[0].array.plot // view frequencies

l[1].array.plot // view amps

Shared controls (Internal server only, control rate only) 

The internal server allocates a number of control buses whose memory addresses are shared with the client. The client can poll these buses without using OSC messages. 

Insert a UGen into your synthdef. Then, on the client side, use s.getSharedControl(num) to read the value. If you want to track the value over time, use a routine to poll repeatedly.

{ var freq;

freq =, 600, 800);, freq); // no need for Impulse here, 0, 0.3) ! 2


l =;

r = fork { loop { l.add(s.getSharedControl(0)); 0.1.wait } };


l.array.plot;  // to view the results graphically 

Server-side trace 

The /n_trace message causes the server to print a list of all the UGens in the node as well as their input and output values. 

It takes some practice to read a synthdef trace, but it's the ultimate source of information when a synthdef is not behaving as expected. Signal flow can be identified by looking at the numbers at inputs and outputs. When a UGen's output feeds into another's input, the values will be the same at both ends.

For a concrete example, let's look at a synthdef that doesn't work. The intent is to generate a detuned sawtooth wave and run it through a set of parallel resonant filters whose cut-off frequencies are modulating randomly. We run the synth and generate the trace (reproduced below). The trace comes out in monochrome; colors are used here to highlight signal flow.

SynthDef(\resonz, { |freq = 440|

var sig, ffreq;

sig =[freq, freq+1], 0.2);

ffreq =, 1, 0.5);,, (800, 1000..1800) * ffreq, 0.1))


a = Synth(\resonz);


TRACE 1005  resonz    #units: 21

  unit 0 Control


    out 440

  unit 1 BinaryOpUGen

    in  440 1

    out 441

  unit 2 Saw

    in  441

    out 0.451348

  unit 3 BinaryOpUGen

    in  0.451348 0.2

    out 0.0902696

  unit 4 Saw

    in  440

    out -0.367307

  unit 5 BinaryOpUGen

    in  -0.367307 0.2

    out -0.0734615

  unit 6 LFNoise1

    in  2

    out -0.836168

  unit 7 BinaryOpUGen

    in  -0.836168 0.5

    out -0.336168

  unit 8 BinaryOpUGen

    in  800 -0.336168

    out -268.934

  unit 9 Resonz

    in  -0.0734615 -268.934 0.1

    out 843934

  unit 10 BinaryOpUGen

    in  1000 -0.336168

    out -336.168

  unit 11 Resonz

    in  0.0902696 -336.168 0.1

    out 3.02999e+08

  unit 12 BinaryOpUGen

    in  1200 -0.336168

    out -403.402

  unit 13 Resonz

    in  -0.0734615 -403.402 0.1

    out 9.14995e+10

  unit 14 BinaryOpUGen

    in  1400 -0.336168

    out -470.635

  unit 15 Resonz

    in  0.0902696 -470.635 0.1

    out -5.42883

  unit 16 BinaryOpUGen

    in  1600 -0.336168

    out -537.869

  unit 17 Resonz

    in  -0.0734615 -537.869 0.1

    out 515.506

  unit 18 BinaryOpUGen

    in  1800 -0.336168

    out -605.102

  unit 19 Resonz

    in  0.0902696 -605.102 0.1

    out 32785.2

  unit 20 Out

    in  0 843934 3.02999e+08 9.14995e+10 -5.42883 515.506 32785.2


Two problems leap out from the trace: first, there are six channels of the output (there should be 1), and second, all the outputs are well outside the audio range -1..1. The first is because we use multichannel expansion to produce an array of Resonz filters, but we don't mix them down into a single channel. 

The above trace uses colors to track the source of each output signal. Note that there are no out of range signals prior to each Resonz. Looking at the Resonz inputs, we see that the frequency input is negative, which will blow up most digital filters. 

The resonance frequency derives from multiplying an array by a LFNoise1. Tracing back (the red, italicized numbers), the LFNoise1 is outputting a negative number, where we expected it to be 0.5..1.5. But, the mul and add inputs are reversed! 

If you look very carefully at the trace, you will see another problem relating to multichannel expansion. The two components of the detuned sawtooth go into alternate Resonz'es, where we expected both to go, combined, into every Resonz. To fix it, the sawtooths need to be mixed as well.

SynthDef(\resonz, { |freq = 440|

var sig, ffreq;

sig =[freq, freq+1], 0.2));

ffreq =, 0.5, 1);,, (800, 1000..1800) * ffreq, 0.1)))


a = Synth(\resonz);


Debugging client-to-server communication

Some bugs result from OSC messages to the server being constructed incorrectly. Julian Rohrhuber's DebugNetAddr is a convenient way to capture messages. The class may be downloaded from: 

To use it, you need to quit the currently running local server, then create a new server using a DebugNetAddr instead of a regular NetAddr. Messages will be dumped into a new document window.


Server.default = s ='local-debug', DebugNetAddr("localhost", 57110));


s.makeWindow; // optional

latency nil // these messages get sent on bootup

[ "/notify", 1 ]

latency nil

[ "/g_new", 1 ]

a = {, 0, 0.4) ! 2 }.play;

latency nil

[ "/d_recv", "data[ 290 ]", [ 9, "-1589009783", 1001, 0, 1, 'i_out', 0, 'out', 0 ] ];

latency nil

[ 11, 1001 ]

Debugging client code 


SuperCollider does not have a step trace function, which makes debugging on the client side tougher, but not impossible. 


Learning how to read SuperCollider error output is absolutely essential. Error dumps often (though not always) contain a great deal of information: what the action was, which objects are being acted upon, and how the flow of execution reached that point.

See the Understanding-Errors help file for a tutorial. 

There's also a graphic Inspector for error dumps, which is enabled with the following command:

Exception.debug = true; // enable

Exception.debug = false; // disable 

In most cases, this will give you more information than a regular error dump. Usually the regular error dump is sufficient. If you are using Environments or prototype-style programming, the graphic inspector is indispensable.

Debug output using post statements

The most common approach is to insert statements to print the values of variables and expressions. Since the normal printing methods don't change the value of an expression, they can be placed in the middle of the statement without altering the processing flow. There's no significant difference between:

if(a > 0) { positive.value(a) };


if((a > 0).postln) { positive.value(a) }; 

Common methods to use are: 


.postcs // post the object as a compile string

.debug(caller) // post the object along with a tag identifying the caller

.debug is defined in the crucial library, so Linux and Windows users may not have access to it. It's used like this:


var positiveFunc;

positiveFunc = { |a|

a.debug('positiveFunc-arg a');



a = 5;

if (a > 0) { positiveFunc.value(a) };


// output:

positiveFunc-arg a: 5


The caller argument is optional; however, it's very helpful for tracing the origin of erroneous values. 

Another advantage of .debug is that it's easier to search for debug calls and differentiate them from legitimate postln and postcs calls.

To print multiple values at one time, wrap them in an array before using .debug or .postcs. Note that if any of the array members are collections, postln will hide them behind the class name: "an Array, a Dictionary" etc. Use postcs if you expect to be posting collections.

[val1, val2, val3].debug(\myMethod); // or, for a non-Crucial way:

[\callerTag, val1, val2, val3].postcs;

By sprinkling these throughout your code, especially at the beginnings of functions or methods, the debugging output can give you a partial trace of which code blocks get visited in what order.


If you discover that a particular method or function is being entered but you don't know how it got there, you can use the .dumpBackTrace method on any object. You'll get what looks like an error dump, but without the error. Execution continues normally after the stack dump.


var positiveFunc;

positiveFunc = { |a|

a.debug('positiveFunc-arg a');




a = 5;

if (a > 0) { positiveFunc.value(a) };


// output:

positiveFunc-arg a: 5


< FunctionDef in closed FunctionDef >

arg a = 5

< closed FunctionDef >

var positiveFunc = <instance of Function>


arg this = <instance of Interpreter>

var res = nil

var func = <instance of Function>


arg this = <instance of Main>


This tells you that the function came from interpreting a closed FunctionDef (automatically created when evaluating a block of code).

In a method definition, it's recommended to use "this.dumpBackTrace"; in a free-standing function, there is no "this" so you should pick some arbitrary object.

Tracing streams

To see the results of a pattern, use the .trace method. Each output value from the pattern gets posted to the main output.


p = Pbind(\degree, Pwalk((0..14), Pstutter(Pwhite(1, 4, inf), Prand(#[-2, -1, 1, 2], inf)), Pseq(#[-1, 1], inf), 0), \delta, 0.25, \sustain, 0.2, \instrument, \default);


Debugging infinite loops or recursion


This is a bad idea. It will lock up SuperCollider and you will have to force quit. Sometimes this happens in your code and the reason isn't obvious. Debugging these situations is very painful because you might have to force quit, relaunch SuperCollider, and reload your code just to try again. 

f = { |func| func.value(func) };


Infinite recursion, on the other hand, is more likely to cause SuperCollider to quit unexpectedly when the execution stack runs out of space.

In Mac OS X, inserting "post" or "debug" calls will not help with infinite loops or recursion, because posted output is held in a buffer until execution is complete. If execution never completes, you never see the output. 

One useful approach is to insert statements that will cause execution to halt. The easiest is .halt, but it provides you with no information about where or how it stopped, or how it got there. If you want a more descriptive message, make up an error and throw it:


When debugging code that crashes, place a line like this somewhere in the code. If you get the error output, you know that the infinite loop is happening after the error--so move the error.throw later and try again. If it crashes, you know the infinite loop is earlier. Eventually, after a lot of heartache, you can zero in on the location. 

Here is a rogues' gallery of infinite loop gotchas--things that don't look like infinite loops, but they will kill your code quicker than you can wish you hadn't just pushed the enter key:

i = 0;

while (i < 10) { i.postln; i = i+1 }; // crash

While loop syntax is different in SuperCollider from C. The above loop means to check whether i < 10 once, at the beginning of the loop, then loop if the value is true. Since the loop condition is evaluated only once, it never changes, so the loop never stops. The loop condition should be written inside a function, to wit:

i = 0;

while { i < 10 } { i.postln; i = i+1 };

Routines and empty arrays:

a =;

r = Routine({

loop {{ |item| item.yield });


});; // crash

This looks pretty innocent: iterate repeatedly over an array and yield each item successively. But, if the array is empty, the do loop never executes and yield never gets called. So, the outer loop{} runs forever, doing nothing. 

Recursion is often used to walk through a tree structure. Tree structures are usually finite--no matter which branch you go down, eventually you will reach the end. If you have a data structure that is self-referential, you can easily get infinite recursion:

a = (1..10);

a.put(5, a); // now one of the items of a is a itself

a.postcs; // crash--postcs has to walk through the entire collection, which loops on itself 

Self-referential data structures are sometimes an indication of poor design. If this is the case, avoid them.

a = 0;

SystemClock.sched(2, { a.postln }); // crashes when scheduler fires the function

When a scheduled function executes, if it returns a number, the function will be rescheduled for now + the number. If the number is 0, it is effectively the same as an infinite loop.

To fix it, make sure the function returns a non-number.

a = 0;

SystemClock.sched(2, { a.postln; nil });

Removing debugging statements

Use formatting to help your eye locate debugging statements when it's time to remove them. SuperCollider code is usually indented. If you write your debugging statements fully left-justified, they're much easier to see.

a =;

r = Routine({

loop {

"debugging".postln; // looks like regular code, doesn't stand out{ |item| item.yield });


});; // crash

// vs:

a =;

r = Routine({

loop {

"debugging".postln; // this obviously sticks out{ |item| item.yield });


});; // crash