/ Topics / ChucK

Wherein we introduce ChucK!

ChucK

The powerful open-source sound engine that can be controlled programatically. ChucK is at the heart of Fiddle and is included in the Fiddle package so you don't have to install it separately. This also minimizes potential compatibility issues.

Also included in the Fiddle package is a searchable version of the ChucK Docs. In the default layout, the Chuck Docs Tab appears in the top right panel, next to these Fiddle Docs.

Also included are all of the standard ChucK examples. When you navigate to a particular example you'll see the ChucK code (a .ck file) is syntax highlighted. Also, if you right-click you'll see this menu:

If you are reading this inside Fiddle, try to "ChucK it!" yourself after clicking here. If all goes well you're now listening to the sonification of a recursive solution to the Tower of Hanoi puzzle.

From this example, we've discovered a few Fiddle features:

• it's easy to explore all of the standard ChucK examples.
• when an example interests you:
  • it's easy to submit it to ChucK (via 'ChucK It!').
  • it's easy to modify the script by copying it to your workspace, then opening a Code Editor session by clicking on the file.
• you can view and control one or more ChucK sessions via ChucK VM Control Panel.

These simple capabilities make it really easy to learn ChucK! It's possible to build entire ChucK compositions with only these tools but we hope you'll take advantage of other Fiddle goodies.

ChucK's Unique Architecture

ChucK was introduced in 2003. It offered a novel sound-processing architecture delivering:

• A precise timing model that is capable of true concurrency and arbitrarily fine granularity. The language semantic supports multiple, simultaneous, and dynamic control rates, and naturally amortizes operations over time.
• Native language support of arbitrarily many input/output sources, MIDI, network, serial, USB, graphics, and any input/output device you can connect to the computer.

Nowdays, this architecture can still be described as novel in that it operates at the level of the individual sound samples. Your ChucK programs are evaluated on each sample, offering an unusual degree of control to the high-level programmer. And literally zero additional latency.

In contrast, a typical sound engine processes buffers of 256-4096 samples at a time. Engines operate this way to maximize the number of separate audio synthesis/analysis components that can run "simultaneously". Larger buffers amortize the cost of context switching. And less context switching means more raw sonic processing power. Many systems distinguish between audio-rate and control-rate frequencies as a compromise between performance and expressivity, noting that control changes that occur at frequencies of .1-100 updates per second, can solve most audio control problems.

From an expressivity point-of-view, the ChucK approach is superior. The notion of "sample accuracy" is fundamental to ChucK's execution model, while many engines have to perform modest contortions to offer this capability. On the other hand, if maximizing audio computation is your goal, ChucK's approach will inevitably draw the short end of the stick.

Sample-accuracy is a luxury and the real question is, can you afford it? In a head-to-head comparison of sound engines on the basis of pure processing power, ChucK is bound to lose the battle. On the other hand, if you don't bump into ChucK's speed limit, then the gain in expressive power will be worth it. In 2003 ChucK was described as running on commodity operating systems (and computers of that day). Now, armed with 20 years of Moore's law, we have orders of magnitude more performance at our fingertips.

So we leave it to you, dear reader, The Lady, or the Tiger?