The Kyma Language for Sound Design, Version 4.5

TimeController is a little less extreme; it merely changes the rate at which time passes on the Capybara. If
you set the Rate to 0, however, it too will stop time.
The input to a WaitUntil module will not be loaded into the Capybara until Resume is triggered; then the
input plays through at its normal rate and for its normal duration.
These modules affect the time-counter that the Capybara uses in order to determine when to start/stop
Sounds and when to issue events. ‡ Thus, they have an effect on things like Concatenations and TimeOffsets,
and MIDI files or scripts in the MIDIVoice. They do not have any effect on the sampling rate. For
example, a TimeController would have no effect on the speed of playback of a DiskPlayer, but if that
DiskPlayer were concatenated with an Oscillator, a TimeController could delay the time at which the
DiskPlayer ended and the Oscillator began.
Suppose you have a situation (say a live, musical performance or a psychoacoustical experiment) where
you know the ordering of the Sounds, but you would like to give the performer (or the subject) control
over exactly when the Capybara switches from one Sound to the next. If you put each of the Sounds into
a WaitUntil, and then feed all of them into a Concatenation, you can control the exact time at which each
Sound is loaded into the Capybara, according to the conditions you place in the Resume field. The change
from one Sound to the next is instantaneous (to within a single sample-tick), because all of the Sounds
have already been compiled and loaded into the memory of the Capybara and are just waiting for their
chance to get loaded and start playing!
For example, say you had three sections, each with a different kind of processing on the ADInput. You
would like the performer to have control over when to start and when to move on to each succeeding
section. The first WaitUntil’s Resume field might have a MIDI switch in it, so the performer could start
things by depressing a foot-switch or by pressing a button on a controller. The next WaitUntil might
have a test on the output of a FrequencyTracker on the ADInput so that the next section would not begin
until the performer sustained a 5 c. The last WaitUntil might have a test weighing the strength of the
higher partials relative to the strength of the lower ones in order to detect when the performer speaks an
“s” (or to detect an attack transient of a musical instrument).
Time (and time again)
When we speak of time in Kyma, there are actually several different time scales that we could be talking
about:
♦ The rate at which the structure is changing.
♦ The asynchronous Event Values that could be coming from MIDI or generated internally.
♦ The rate of Sounds pasted into parameter fields as control signals.
♦ The sampling rate, the rate at which the audio signals are computed.
The structure-changing rate is the rate at which old Sounds may expire and new ones take their place due
to Concatenations or TimeOffsets. These changes take place “between the samples”, that is, there is no
delay between terminating one Sound and loading/starting the next. In order for this to work, though, all
of the changes must be specified in advance.
Event Values are asynchronous updates to the parameter values of the Sound that is currently loaded on
the Capybara. These could be coming in live from MIDI devices, a MIDI sequencer, generated by the
AnalogSequencer, or they could be read from a stored sequence like a MIDI file or the sequence generated
by a script in a MIDIVoice. In all cases, though, the input is not necessarily periodic and it is not always
known in advance when an event might come in. The maximum rate of change for these asynchronous
events is once per millisecond, corresponding with the maximum rate of transmission for the MIDI interface.
Sounds pasted into parameter fields are often used in expressions that include Event Values, so the
maximum rate of LFO-like control updates is also set at once per millisecond (or 1 khz).
‡ The Event Values called !Time (time in seconds since the start of the entire Sound) and !LocalTime (time in seconds
since the start of the Sound referencing !LocalTime) are also affected by these modules. !RealTime (time in
seconds since the start of the entire Sound) is not. These Event Values can be read only, not written.
75