ChucK: Strongly-timed, Concurrent, and On-the-fly Music Programming Language
chuck.cs.princeton.edu
chuck.cs.princeton.edu
He likes to refer to it as "strongly timed", and I think it is a really accurate description. While the language does have limitations, it can also be beautifully expressive for certain things.
If anyone has any question for the author please let me know and I'll either get him to come in here or be a surrogate and answer directly
When I was doing my master thesis on this domain, another student in the lab (who was from an IRCAM [4] master degree) worked on the use of synchronous languages to follow a musician who plays at arbitrary speed a given music score (or something along those lines). It was quite fun!
[1] https://en.wikipedia.org/wiki/Lustre_%28programming_language...
[2] https://en.wikipedia.org/wiki/Esterel
[3] https://en.wikipedia.org/wiki/SIGNAL_%28programming_language...
Time/Duration are data types, and you must advance "now" to generate samples and events.
I don't understand ChucK or Extempore well enough at a lower level (yet) to provide a good comparison, but I'm just happy to see people introduced to any music hacking tools. :)
[0] http://extempore.moso.com.au/ [1] http://vimeo.com/groups/82430/sort:plays/format:thumbnail [2] http://impromptu.moso.com.au/
Even CSound has had resurgence with iOS apps. Likewise with Pd. I'm really liking the haskell based sample player Tidal, that's a lot of fun.
There are many other systems that are similar, including SuperCollider, Max/MSP, PureData, CSound and JSyn/JMSL.
I think the intuition behind ChucK is similar to the functional reactive programming of Elm [1]. But it's doesn't seem as though it's thought completely through. It would be cool to see a true FRP implementation for sound.
I have a long background as a C programmer. Because ChucK is C-like, I have had the least trouble learning it, of the 4 languages mentioned above. The simple stuff I implement in ChucK tends to work the first time. However, my musician friends who are not C programmers tend to find visual patching languages (like PureData and Max) far more intuitive.
Performance-wise, ChucK seems to me to be the least performant of the 4 mentioned above, however, for my needs it works fine, and I look forward to doing more work with it.
You can route things to multiple destinations with multiple ChucK operators.
You can also route to specific inputs by naming them.
Arbitrary routings are neither impossible nor a problem.
SinOsc A => dac.left; // Here, A's main output connects to a specific input of object dac.
SinOsc B => dac;
A => B.freq; // Here we see the same A having another output connection, and connecting to a specific input of another object to create FM modulation.
This one's a laid-back idea for a 'chillout' song I haven't finished:
https://soundcloud.com/sigint-trax/national-degeneration-uni...
This one is an experiment that involved the main melody being manipulated randomly by a mutation algorithm I wrote:
it has some really interesting concepts built into the language, like time. but in my experience this doesn't provide huge value for the purpose of composition, especially since when you are writing code livecoding is typically loop based.
i'd love a ChucK VM for the web audio API. on the back burner; things i should do but won't.
Outside of that, you're right -- it's not widely used -- although, at CalArts (where I currently go to college, http://www.calarts.edu), it's extremely popular in the Music Technology department. We use it mainly for handling MIDI->OSC translation to control robotic instruments (http://www.karmetik.com/media) and interfacing other electronics, like custom built musical interfaces and controllers, with music software.
aren't there better tools for MIDI/OSC translation though?
Then I bought a hefty synth and after about 6 months of sounding like a tramp bashing a trash can lid, I finally clicked and it's an extension of my mind now, much like whistling a tune or tapping one out on your knee with your hand.
Now I can write my automatic-jazz-improvisation sequencer!
EDIT: good to see it still has BBCut built into it, for LISPy amen choppage fun.
Now my brain is melting at the thought of recursively defined, lazily-evaluated breakcore. I think I need a lie down.
How does ChucK compares to CSound?
- From what I recall, ChucK doesn't really have any equivalent to CSound's score -- you just procedurally schedule changes. If you've every seen JSyn [1], I think ChucK is roughly equivalent to it, but with the language adapted to be more music centric than Java. JMSL [2] is roughly a Java equivalent to CSound's score file, and I don't know of anything in ChucK that fills that role.
- CSound is not really built for modularity or flexible routing between components. ChucK is better in that regard.
- CSound also has the benefit of a couple decades worth of usage and all sorts of interesting corners to its ecosystem.
I'm sorry if this isn't a very coherent comparison. I haven't used CSound in a few years, and ChucK in even longer. If you're doing classical music, I imagine you'll value CSound's scoring capabilities over ChucK's synthesis flexibility.