Chuck - Concurrent audio programming language

Not sure if this is relavent to LtU but it is a programming language so...

ChucK is a new audio programming language for real-time synthesis, composition, and performance - fully supported on MacOS X, Windows, and Linux. ChucK presents a new time-based concurrent programming model, which supports a more precise and fundamental level of expressiveness, as well as multiple, simultaneous, dynamic control rates, a precise and straightforward concurrency, and the ability to add, remove, and modify code, on-the-fly, while the program is running, without stopping or restarting.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Hacker Background Soundtrack in Chuck

Chuck is nice and I'm sure I'll be using it in the future for some of my composition. Here's a little glitchy cyber sountrack I hacked together (yeah, it's ugly). for those that like infinite space ambient noise soundtracks. I call it 'sporadic equipose rebarbative' (bonus points to those that can figure out how I came up with that :)


Flute flute1 => PoleZero f1 => JCRev r1 => pan2 p1 => dac;
Flute flute2 => PoleZero f2 => JCRev r2 => pan2 p2 => dac;
Flute flute3 => PoleZero f3 => JCRev r3 => pan2 p3 => dac;
Flute flute4 => PoleZero f4 => JCRev r4 => pan2 p4 => dac;

// basic play function (add more arguments as needed)
fun void play(Flute flute, float note, float velocity )
// start the note
std.mtof( note ) => flute.freq;
velocity => flute.noteOn;

// our notes
[ 61, 63, 65, 66, 68 ] @=> int notes[];

std.rand2f(0,0.56) => r1.gain;
std.rand2f(0.0,0.4) => r1.mix;
std.rand2f(0,0.56) => r2.gain;
std.rand2f(0,0.4) => r2.mix;
std.rand2f(0,0.56) => r3.gain;
std.rand2f(0,0.4) => r3.mix;
std.rand2f(0,0.56) => r4.gain;
std.rand2f(0,0.4) => r4.mix;

std.rand2(0, 1) => p1.pan;
std.rand2(0, 1) => p2.pan;
std.rand2(0, 1) => p3.pan;
std.rand2(0, 1) => p4.pan;

fun void doit (Flute flute, int maxlen, PoleZero f, JCRev r, pan2 p, int shift) {
// infinite time-loop
while( true )
std.rand2f(0.0,0.5) => r.gain;
std.rand2f(0.10,0.2) => r.mix;

std.rand2f(0,1) => f1.a1;
std.rand2f(0,1) => f1.b0;
std.rand2f(0,1) => f1.b1;

std.rand2f(0,1) => f2.a1;
std.rand2f(0,1) => f2.b0;
std.rand2f(0,1) => f2.b1;

std.rand2f(0,1) => f3.a1;
std.rand2f(0,1) => f3.b0;
std.rand2f(0,1) => f3.b1;

std.rand2f(0,1) => f4.a1;
std.rand2f(0,1) => f4.b0;
std.rand2f(0,1) => f4.b1;

// clear
// flute.clear( 1.0 );

// set
std.rand2f(0,0.3) => flute.jetDelay;
std.rand2f(0.2, 0.5) => flute.jetReflection;
std.rand2f(0.1, 0.3) => flute.endReflection;
std.rand2f(0,0.05) => flute.noiseGain;
std.rand2f(0,5) => flute.vibratoFreq; /* 0 - 12 */
std.rand2f(0,0.2) => flute.vibratoGain;
std.rand2f(0.2,0.9) => flute.pressure;

// factor
std.rand2f( .75, 2 ) => float factor;

for(int i; i std.rand2f(0.2, 0.8) => p.pan;
std.rand2(0, 50) => int note;
std.rand2f(.2, .5) => float vol;
play(flute, note, vol);
std.rand2f(0,maxlen)::ms * factor => now;


spork ~ doit(flute1, 11600, f4, r4, p4, 37);
15000::ms => now;
spork ~ doit(flute2, 8800, f3, r3, p3, 44);
15000::ms => now;
spork ~ doit(flute3, 4400, f2, r2, p2, 40);
15000::ms => now;
spork ~ doit(flute4, 2200, f1, r1, p1, 32);
15000::ms => now;
spork ~ doit(flute4, 1600, f4, r4, p4, 37);
15000::ms => now;
spork ~ doit(flute3, 800, f3, r3, p3, 44);
15000::ms => now;
spork ~ doit(flute2, 666, f2, r2, p2, 40);
15000::ms => now;
spork ~ doit(flute1, 333, f1, r1, p1, 32);

while(true) {
1000::ms => now;

Burton Samograd


I am the author of SuperCollider which is also a programming language for real time audio synthesis. A number of misstatements about SuperCollider have been made in the papers on ChucK.

SuperCollider is no less concurrent than ChucK, and is no less "strongly-timed" than ChucK. Every thread in SuperCollider carries with it a time reference in a certain clock base. Clocks can run at different tempi. ChucK doesn't handle tempo.

// fork two concurrent threads in SuperCollider: 
fork { { "A".postln; 0.2.wait } };
fork { { "B".postln; 0.1.wait } };

Indeed, a number of claims about ChucK seem to be based on its limitations. Chuck runs its threads inside the audio calculation loop which means that any long large calculations will stall the audio and cause a glitch. SuperCollider is based on a client/server model which decouples event generation from audio synthesis.

Chuck lacks higher order or anonymous functions, whereas SuperCollider has closures, map/filter/fold, currying, list comprehensions, tail call optmization, etc.


To be honest, when I looked at Supercolider I coun't really get into it due to it's unfamiliar syntax. It's been a while since I looked, but I was wondering what you based it on.

syntax similar to Ruby

It isn't that unusual, it is very similar to Ruby. SuperCollider wasn't based on Ruby, it was based on Smalltalk, but Yukihiro Matsumoto and I coincidentally happened to have made many of the same choices in syntax, such that I was subsequently able to borrow some of Ruby's syntax features that I didn't already have. And since both Ruby and SuperCollider are both in the Smalltalk family, they also share many of the same method names.


Then I guess that's why I don't use Ruby either (and find Smalltalk a bit of a strain on the eyes as well :) Like I said it's been a while since I've looked at both, but I'm sure in the future I'll be testing out my syntactical transformation skills, althought I have to say that I prefer C-like syntax...

Can't get started.

I've tried to use SuperCollider several times, and been unable to do anything with it.
I can install the debian packages and start up the server, but I cannot figure out how to send sound events to the server from the client.
I really want to create more services like schearnet, but how?
I've read the included documentation, and tried to find the 'baby steps' docs on the website, but I have had no success.

sc-users mailing list


Not sure if this is relavent to LtU but it is a programming language so...

Why wouldn't this be appropriate for LtU?

I guess that while on this topic we should also mention Haskore.


One of the reasons I've wanted to learn Haskell has been to use Haskcore. I'm finding, especially after using Chuck, that a langnuage which combines synthesis and composition is much more useful, rather than one that just outputs MIDI to be fed into various synths and samplers. I guess that would be where I would like a larger, more complete solution for audio and signal processing, since setting up sample banks and MIDI routing is generally quite a pain in the butt when you just want to sit down and write a song.

Also, don't forget to mention keykit, an incredibly powerful MIDI sequencing language and interface. I would consider keykit the emacs of the music world and it comes with plenty of interesting sequencing toys to play with and get yourself started.

Good Name

For some reason, I really like reading all the positive comments in this thread ;)

Just adding a little noise to the signal...

Time relationships between parts

As someone who is attempting to write a music description/synthesis language, I am interested in how well the language expresses the time relationships between different threads of music. There seems to be a basic problem in writing down music as a one-dimensional sequence of symbols, in that events that should be heard together are described one after another in the text.

Conventional music notation solves this by being two-dimensional, such that events that occur together are aligned vertically (more or less), while sequences of events are written from left to right.

I have tried to do something like conventional music notation by having bars or measures, each of which contains a set of parts. Each part contains a sequence of instructions to render the bar for a particular player/instrument. This means that events that occur together are close together in the text. Also, I can apply checks that the total duration of each part adds up to the stated bar length.

rebarbative comment

About Krufht chuck script, there's a syntax error on line 69 : "for(int i; i " should not be there. Delete this and it'll work nice!

Is it just me...

or have the spammers been extra busy this month?

What I want to know is...

...if a guy who's been a registered member for 8 seconds can successfully post a dozen messages consisting entirely of hyperlinks (with labels that require unicode and all to the same domain) to a dozen threads that have been inactive for years, then what exactly does the spam filter do?