Controllers generate parameter value changes,
Control Changes
, at an arbitrary rate. Controllers can change the behavior or sound of any controllable node at any time during a performance. Most Fiddle nodes are at least partially controllable. This means that most parameter values can be modified live via Fiddle's node inspector. It also means that you can control them through your graph.
In the heyday of Analog Synthesis the term LFO
(low frequency oscillator)
was introduced to distinguish audio rate signals (those we can hear as a tone)
from lower frequency signals that we can employ to modulate an audio signal.
For example an LFO multiplied by an audio signal can produce a tremolo effect.
For this use, the term LFO
is very descriptive. Where the term LFO
has
grown into misuse is when it is used to describe trigger signals or more
arbitrary parameter changes that simply can't be said to oscillate.
In a more modern and more general setting we can view audio synthesis as a
collection of algorithms that are glued together through a network of parameters.
In this view, sound changes occur through parameter changes and the choice of the
rate at which the parameters are changed. Now we can say this: to achieve
a tremolo effect we emply an LFO
(algorithm) to drive a parameter
change to another algorithm (say, its Gain
). And we can also send a CC
that may Trigger
an arpeggiator. This admittedly pedantic diatribe is
presented merely to free your mind
from the shackles of historical jargon (and provide you with some new shackles?).
Now couple this with Chuck's unique architecture
and we can see that a more general term for arbitrarily timed parameter changes
is helpful. Following the MIDI v1 jargon, we thus employ the term Control Change
,
or CC
for this more general setting and this lands us here:
A
Controller
sends arbitrarily timed parameter values,Control Changes
, to connectedControllables
.
In order for Controllers to independently manage event timing they operate in separate ChucK shreds. If an event has a duration, we say that that controlling-shred is blocked. So, if you wish to schedule two events of overlapping durations you need two controllers and two shreds. Loosely speaking the number of controllers you need is the sum of the number of independent audio channels and the number of parameter "automators".
Player is the most common controller. It has two output
ports, Controller
and CC
. Both ports convey the same signals to connected
nodes but it may be convenient to distinguish Instrument connections from more
general CC signal flow. As CC
s flow past a Player it can rename them
by connecting Alias
nodes to CCAliases
. This idea is further
developed in this example.
SessionGrid is be used to schedule or trigger downstream notestreams like NoteGrid. It can play a role analogous to the Timeline or Session View in most DAWs. The Grid Editor is used to produce the session grids files that drive the Session Grid node.
TimeKeeper can be employed as a controller to
signal important state changes that occur during a performance.
TimeKeeper emits CC
triggers like TkStart
, TkStop
, TkMeasure
, TkBeat
and these can be used, for example, to control recording intervals.
We should note that these signals are trigger-like and thus have no duration.
This means that you can wire any number of Controllables
to a single
TimeKeeper.
CCSampler is a simple node that produces
a fixed rate CC stream by sampling an arbitrary audio signal that you connect.
You also pick a sample rate, remap input values to a different output range,
and pick the CC name. The result is a very flexible node that can deliver
a multitude of automated CC features that include the typical LFO
applications.
To diagnose issues with your setup this node also includes an optional
signal plotting capability.
CCGenerator is very similar to CCSampler
.
The primary difference is that it doesn't require an upstream signal to sample.
Rather, a fixed-rate control signal is generated internally from a menu of
simple input signals: Random
, Random Walk
, Perlin
and Sine
. Also
because the input signals are limited and well-defined CCGenerator doesn't
include the plotting options.
CCMouse produces a variable-rate control signal
that allows you "paint" control signals with your mouse. CCMouse
produces
a number of control signals including MouseX
, MouseDX
, MouseY
, MouseDY
,
WheelDY
and MouseB1
. Values can be scaled and remapped by CCMouse parameters
and these CC names can be remapped via its CCAliases
parameter.
PitchTracker is a simple controllable
wrapper for ChucK's PitchTrack Chugin.
This produces a variable-rate control signal that includes NoteOn
messages
(but not NoteOff
) and thus can be connected to instruments. The result is
akin to auto-tuning especially if you connect a vocal track as input. Note
that this approach is not intended to fill the role of a real auto-tuner but
it can produce interesting results.
The fact that all nodes that can be edited live are Controllable
means
that they can also partake in graph-based control. Even Controllers
are
themselves Controllable
. Because nearly all Fiddle nodes are Controllable the
same principles apply and we can keep our tour of Controllables
brief
and generic. The key indicator of a Controllable is that it has
a Controller
input parameter.
Consider this graph:
By inspection we see that a CCSampler is plugged into Chan0_1 and thus must be controlling some aspect of the Channel node. Additionally we see that the CCSampler is sampling a SinOsc output, so it's sending a sine wave to the Channel.
Four important facts about the behavior lurk within the node values:
Since we've provided you with the example file we'll leave it as an exercise to the reader to unravel these mysteries.