Chuck: An Audio programming language - it's like a dream come true.(chuck.cs.princeton.edu)
chuck.cs.princeton.edu
Chuck: An Audio programming language - it's like a dream come true.
http://chuck.cs.princeton.edu/
8 comments
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?
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?
There's a tutorial here:
http://chuck.cs.princeton.edu/doc/learn/tutorial.html
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.
http://chuck.cs.princeton.edu/doc/learn/tutorial.html
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.
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:
http://developer.kde.org/~wheeler/images/polysynth-jmax.png
And the same in ChucK:
http://developer.kde.org/~wheeler/files/polysynth.ck
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.)
http://developer.kde.org/~wheeler/images/polysynth-jmax.png
And the same in ChucK:
http://developer.kde.org/~wheeler/files/polysynth.ck
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.)
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.
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:
Like look at the functions: http://chuck.cs.princeton.edu/doc/language/func.html
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.
Right from the tutorial:
// connect sine oscillator to D/A convertor (sound card)
SinOsc s => dac;
// allow 2 seconds to pass
2::second => now;
SineOscillator connectTo: digitalToAnalogConverter.
2 seconds wait.
Like look at the functions: http://chuck.cs.princeton.edu/doc/language/func.html
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.
I agree. Every program seemed to have a few "while (true)" lines, often with comments above them like "// infinite time loop" :(
And another example for your earlier point:
// print out the shred id <<< me.id(); >>>;
And another example for your earlier point:
// print out the shred id <<< me.id(); >>>;
If you know you're going to have infinite time loops, you might as well make a new control structure and call it `loopForever` or whatever.
There are similar things. Here's a lisp-based one,
http://commonmusic.sourceforge.net/doc/cm.html
http://commonmusic.sourceforge.net/doc/cm.html
I was hoping for a programming language for writing software using only a microphone and speakers.
Great video on Chuck here: http://www.youtube.com/watch?v=2rpk461T6l4
The term "strongly-timed" is amusing. Too bad it doesn't really mean anything.
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:
In ChucK you have different "shreds" (threads) where you advance time explicitly by doing something like:
1::second => now;
1::minute / beatsPerMinute => dur beatLength;
for(0 => int i; i < 4; i++)
{
spork ~ snare();
beatLength => now;
}
How does this compare to Pd (Pure Data) and Max? It's "real code"?
Yes - more like supercollider than connecting boxes.
And unlike SuperCollider, the syntax isn't shite.
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.)