ChucK is pretty awesome if you're into audio programming. The syntax is infinitely cleaner than CSound or SuperCollider and I find writing real code more effective than trying to do visual programming with MAX and friends. I love the model for time advancement in multiple "shreds".
The only sad thing is that it's not really managed to make the leap to a community project. It's still mostly a Princeton Sound Lab / Ge Wang (previously there, now at Stanford) project and I'm uncertain, well, sadly, skeptical, that it will ever really fully mature. It's still got some rough edges and there's not been very little progress on it in the year and a half that I've been using it. The couple of times I've submitted patches they've been ignored.
I've written a bunch of useful boilerplate classes and a preprocessor for it to allow includes, if anyone's interested. (These have also been posted to the chuck-users list.)
Cool - what are the main use cases? I mean, looking at the common kinds of things people would create with ChucK, is it much better than the alternative tools, or just better for the people who have programming oriented minds?
Well, it's used for music, so, i.e. composing a piece of music where you wanted to have fine grained control over the synthesis, timing or sampling. The alternatives are still basically programming, just done in a visual environment rather than in code. Here's an example in Max:
There are other more concrete examples mentioned in some of my posts here. (Didn't post the article, but I've been one of the more active people on the ChucK mailing list for a long while now, so it was a surprise to see it turn up here.)
Sorry to sound like a complete amateur, but what can sound programming achieve?
Is it more than just sequencing samples or transforming input with code? Can it create samples? If so, is there any decent documentation on this for the beginner?
These days synthesizers, samplers and whatnot are naturally just software. If you want to have fine-grained control of how synthesis, sampling or other sound manipulation is done, it's often useful to have a programming environment specifically made for that. The competitors that I mentioned to ChucK in my last comment are the best known environments for such.
I personally use ChucK mostly to process MIDI instructions and reroute them to a separate synthesizer or to send control signals to a sequencer. For instance, in one case I wanted to play a pattern of notes at an increasing tempo stretched to the track's tempo using a specific function of time so that the notes would be in synch / out of synch with the original in a predictable pattern. Doing that was reasonably easy to hook up with ChucK.
Damn, when I thought that I spend more time tweaking knobs than playing music, something like Chuck appears... no! go away! I don't want to play with you and get hooked!
I'm terribly unproductive with music, and this is just one more way of procrastination :). Very cool, though. I can see why writing programs for a standard language makes sense.
Imagine that you want to write some music that can be reproduced anywhere with any hardware. Kind of like sheet music for orchestral works. This may be the only way. Right now, we have problems to reproduce analog synthesizers from the 50's-70's. For example, Bernard Hermann 'It's alive II" soundtrack has a great synth lead (together with an orchestral arrangement). If some orchestra wanted to play that work live in say 100 years, good luck finding a working synth to reproduce that sound exactly. Of course, software replicates anything, but it may never be the same thing. On the other hand, a violin is the same as a violin 100 years ago (I hope).
Things like Chuck fix this problem. You can write electronic music that is 100% reproductible 100 years from now.
You're wrong about the violin. You still have to tune it in a certain way to get the same sound. The temperature and body structure and wood and all that affect the sound. So sheet music and knowing the scales is really the best we have. For synth stuff it would be nice to get exact formulas for how the synths produce the sound, but I guess that's considered a trade secret?
This is fucking stupid stupid stupid. I have the same complaint for it as I have for Processing. The code should document itself and should not be cryptic.
Right from the tutorial:
// connect sine oscillator to D/A convertor (sound card)
SinOsc s => dac;
// allow 2 seconds to pass
2::second => now;
Why should a sound/audio engineer be concerned with the return type of a function? Have one simple rule: every function returns something. Static typing makes sense for optimization but I would expect at least some minimal level of inference.
Yet another language designed for creative work that's hindered by the illogical mind of a programmer.
If you've worked in music programming languages it does. One of the major problems with the widespread visual programming environments (Max, Reaktor) is that they mix signal flow and time flow in often unclear ways.
In ChucK you have different "shreds" (threads) where you advance time explicitly by doing something like:
1::second => now;
That makes the flow of time between different elements very clear and in theory (though not always in practice) it's sample accurate between different shreds. Durations are an ordinal type in ChucK, so you can also do something like:
1::minute / beatsPerMinute => dur beatLength;
And then do:
for(0 => int i; i < 4; i++)
{
spork ~ snare();
beatLength => now;
}
Where "snare()" is a function that plays a snare drum sample and "spork ~" spawns a new shred to play that sample (where time is advanced independantly).
The only sad thing is that it's not really managed to make the leap to a community project. It's still mostly a Princeton Sound Lab / Ge Wang (previously there, now at Stanford) project and I'm uncertain, well, sadly, skeptical, that it will ever really fully mature. It's still got some rough edges and there's not been very little progress on it in the year and a half that I've been using it. The couple of times I've submitted patches they've been ignored.
I've written a bunch of useful boilerplate classes and a preprocessor for it to allow includes, if anyone's interested. (These have also been posted to the chuck-users list.)