/ Topics / ChucK Live

Wherein ChucK comes alive.

Overview

The term, ChucK Live, represents a collection of interactive behaviors that Fiddle adds to the basic ChucK command-line experience.

These features are achieved through a combination of ChucK programs, aka the Fiddle Runtime ("runtime"), and associated components within Fiddle itself.

Fiddle's ChucK Live features allow you to interactively:

• adjust tempo
• adjust pan, gain, mute, solo for channels and channel groups
• manipulate note streams while they are playing
• modify instrument parameters live
• plot signals depicting aspects of your running ChucK programs

In addition to allowing you to interactively modify inputs to ChucK programs, the same underlying mechanism allows you to programmatically modify these properties.

The information provided below is presented in the vocabulary of the Graph Editor and targets the non-programming use-case. The capabilities are generally available to any ChucK program that uses the runtime's classes and conventions and if you are in this audience another doc may be helpful.

Making Music

At the end of the day we only wish to produce a musical experience. How hard can that be? Mind you, this is a separate question from how good it is, so our focus here addresses only the first question. What form should a program take to produce a musical experience?

The traditional musical setting offers many concepts that translate directly into a computer-programmable form. After all, a musical score is a sort of program. It describes a bunch of notes or events and assigns them to a collection of one or more players (performers). A conductor's job is to keep the players in temporal sync and to guide aspects, eg. volume, timbre, of the players' performances.

Central to musical performance is the idea of multiple simultaneously evolving signals. In other words, players are autonomous and asynchronous agents. It turns out this nicely maps onto ChucK's notion of shreds.

The Fiddle Runtime implements classes that follow this traditional paradigm. A Player receives notes from a NoteStream. Notes received through this stream are described in terms of a canonical beat and it is the job of the TimeKeeper to define the current duration of a beat in an evolving composition.

Next, it's the player's job is to operate its Instrument. It does this by sending appropriate control messages to connected instrument(s).

Finally, the output of the instrument is routed to a Channel where effects can be added. Channels can route their output to other channels, resulting in channel networks to provide ultimate mixing and effects control.

In our system, the aspect of controlling an instrument's behavior has been generalized to support most classes. A object is said to be controllable if it implements the prescribed behavior and can be uniquely distinguished amongst all controllables in the ChucK session.

This is a long-winded way of saying: a Channel's Mix parameter can be changed via the same mechanism as an Instrument's Tonality. Some synthesis environments distinguish between audio-rate and control-rate signals. The term LFO (Low Frequency Oscillator) is often part of these conversations. In the context of ChucK + Fiddle, this distinction is also useful but not fundamental. Your program can generate control signals at any frequency it likes. And all parameters of all controllable objects can be modified at this rate. In this general setting, a CC Generator can control parameters of any number of objects at any frequency it chooses.

What currently can't be controlled in this manner are edits to the connection network between components. In most cases this isn't a significant limitation. For example, a note-switcher component can route between different note-sources to produce an effect analogous to changing the network. And when network changes are required, it's simply a matter of clearing, then restarting the new configuration.