In my last music technology article I concluded that there were no suitable Python tools for real-time composition and audio processing. In a previous look at specialised music control languages I discovered that some of these offer novel paradigms that might be particularly useful for realtime composition.

As a result, I decided to investigate ChucK. Back in spring 2007, when I initially did this research (sorry to be so tardy writing about it all!) I decided it was yet too immature to warrant deep study. But improvements have been steady, and as of 30 August were dramatically improved with the ASIO patch to version 1.2.1.0.

After downloading this tweaked ChucK executable I tried it with a simple example patch file from the electro-music forum. Wham! Sound! It worked, first time. Amazing OOBE*. Then I tried tweaking it and all sorts of things happened, most of them nice.

I read through some of the list archives and started wondering where all the example files were. Going to the download page I saw that there were two Windows options: "standard command line executable" or miniAudicle , the "experimental integrated editor/VM". So I grabbed these to see what was in them. Both include the docs and examples, not only the components mentioned. Not so clear from the labeling, but maybe obvious in hindsight.

Trying the horrifically named miniAudicle I had a few issues, none of them major. First, it took an awful long time to load. I had thought maybe it was completely broken. Some sort of "loading..." message would reassure.

Next, it detected my RME Fireface drivers but once I changed to these using the preferences dialogue I needed to restart the app. Reasonable perhaps, but annoying considering the aforementioned load time.

Playing back one of the examples I had used before, everything sounded wrong. I determined this was because the sampling rate was very high (192 KHz). I am still not sure why this would have screwed up the sounds, as they were Shakers. Perhaps these are based on samples?

Anyway, setting the rate to 32KHz made things better, but I wonder why these are the only two choices when most audio apps permit standard 44.1KHz, 48KHz etc. Maybe something to do with choosing only the base rates from the sound card.

Editing was nice in the coloured syntax window, especially once I'd set tabs and the font to my liking. I am glad there's a Recent Files list. However, implementing file drag'n'drop from Explorer to the IDE would be a big usability bonus.

The extended keyboard keys do not seem to be supported. This is particularly annoying for my use, since I have a mini keyboard that makes it difficult to use the default Del key (for example).

I started thinking about using miniAudicle in performance. Live coding is one of ChucK's strengths.

The interface lets you start up a virtual ChucK machine and then add files to it individually as Shreds. This is very handy but some sort of global controls for mixing are necessary. Otherwise, the only way to stop a shred (take it out of the mix) is to kill it, which happens abruptly and not always too nicely (in sonic terms). Perhaps the implicit mixer before the DAC could be exposed, along with level and mutes on each channel/shred.

A solution to this might very well be forthcoming on the ChucK mailing list, which has some active and helpful participants.

A further usability issue was revealed when I tried to use a patch from the examples folder that required sound files. These were referred to by relative pathing, but this only works if the script is run in its own folder. It appears there is no way to programmatically specify the root folder. So how does one integrate patches like this into a miniAudicle session? Apparently this is a known issue. And a pretty big one that needs an immediate fix, IMO.

A simple solution would be if a list of paths could be specified in the preferences. The IDE could search these first looking for sound files.

Other deficiencies are evident from the documentation, which is straightforward, honest and comical. Garbage collection is not implemented, so long-running pieces with lots of spawned processes might run out of memory. Some of the sound generators are not yet documented.

But overall I think ChucK is mature enough for anyone interested in experimenting with concurrent audio programming to give it a whirl.

In a follow-on article I'll look at the programming constructs and highlight what makes ChucK so unique.

2 comments:

A word on the sampling rate issue. Running "chuck --probe" returns various info on your soundcard. This told me the default is "ASIO Fireface" with supported sample rates at 7 different frequency points, including 44.1 and 48KHz. So obviously it's the miniAudicle which is having difficulty. If ChucK command line can see them, why not that?

Does miniAudicle not like the Fireface? I have the fireface on my recording workstation computer and, just like you, it takes a LONG time to start. But on my laptop w/ just a some crap sound card it starts instantly. hmmm....