Csound gives a musical note more than one clock

Participants at the Seventh International Csound Conference, held at mdw in Vienna in September 2024. Photograph © mdw/Titas Lasickas, from the project's conference report.[9]

Hold a synthesizer note and slowly open its filter. The gesture feels continuous, but a computer has several jobs to coordinate: start the note, update the filter, calculate the waveform, and deliver samples before the loudspeaker needs them. Csound, the open-source audio programming language, exposes those jobs unusually clearly. Following one note through its architecture explains why a responsive instrument needs more than a small audio buffer.[1][4][7]

This reading uses the Csound 6 reference manual, whose legacy documentation identifies itself as version 6.18.0.[10] The focus is the established score-and-orchestra model, rather than the newer Csound 7 syntax. The interesting question is where each kind of musical instruction becomes work.

A score event borrows an instrument

Csound calls a sound-producing definition an instrument. Instruments combine processing units called opcodes: oscillators, filters, envelopes, and other operations. Together, the definitions form an orchestra. The engine builds their processing chains and activates them in response to a score or real-time events.[1]

A score can contain a line as compact as i 1 0 2 0.15 440. Its opening fields ask instrument 1 to start at time zero and run for two beats. Without a tempo-changing score statement or command-line flag, those beats are interpreted as seconds. The remaining values have no universal musical meaning: instrument 1 must decide how to use them. It might assign p4 to amplitude and p5 to frequency.[3]

That distinction matters when sharing instruments. A column containing 440 is a frequency only because the receiving code treats it as one. Move the same score to an instrument that expects a MIDI note number in that position and its meaning changes. The interface is a small agreement between the event and the sound definition.

An instrument definition can serve overlapping notes; each ordinary note receives its own allocated data space. A chord therefore need not require three separately written synthesizers.[3] The score supplies instances and timing, while the instrument supplies the behavior they share.

One file preserves the division of labor

The orchestra and score can live in separate files, but a .csd document packages them together. Within its outer CsoundSynthesizer element, CsOptions holds launch options, CsInstruments holds definitions, and CsScore holds score instructions.[2]

This packaging makes the relationship easy to inspect. Change the score and the same instrument can play another phrase. Change the instrument and the same events can acquire another sound. Keeping both in one document does not erase their separate responsibilities.

Dave Phillips's April 2005 Linux Journal article documented this move from paired files to a unified document while examining Csound 5.[8] That independent historical account gives useful perspective: the convenience of a single project file was already being built around a durable separation between musical events and synthesis. It is a reason this older model remains worth reading, even when a graphical interface supplies the events.

The letters describe time

Inside a traditional Csound instrument, variable prefixes communicate when values change. An i variable is established during initialization; a k variable updates at control rate; an a variable carries audio-rate data.[4]

For the simple note above, an initialization variable can hold the starting pitch. A control signal can describe a changing filter setting. An audio signal holds the waveform that will eventually reach the output. These choices express the temporal detail each part needs.

There is a subtle implementation point behind the notation. Audio-rate variables carry vectors of samples processed during each control pass. Csound can calculate a block of audio in one pass while preserving a distinct value for every sample. A control-rate scalar supplies one value for that period.[4] Block processing does not mean the waveform itself has been reduced to one sample per block.

The orchestra's ksmps setting determines how many audio samples fit into a control period. The relationship is kr = sr / ksmps, where sr is the sample rate and kr the control rate.[5] With an illustrative sr = 48000 and ksmps = 32, there are 1,500 control periods per second, each about 0.667 milliseconds long. At ksmps = 128, that becomes 375 periods per second, about 2.667 milliseconds each. These are calculations from the documented relationship, not performance measurements.

Both settings still describe audio at 48,000 samples per second. What changes is the spacing of control updates. Confusing those two resolutions makes it difficult to diagnose a sweep that sounds stepped even though the recorded waveform has the expected sample rate.

Smoothness has its own operation

Csound's interp opcode makes the distinction audible. It converts a control signal to an audio signal using linear interpolation between successive control values. The manual demonstrates the result with a deliberately large control block: a changing amplitude sounds rough in one instrument and smoother in another that interpolates the envelope.[6]

Interpolation fills the space between supplied values. It does not create additional knowledge of what a performer did between input updates. That is the useful boundary: smoothing a parameter and capturing it more frequently are different operations. A musician may want both, but one cannot be used as evidence that the other occurred.

For an instrument builder, this suggests a focused experiment. Keep the sample rate fixed, compare control-block sizes, and then compare the parameter with and without interpolation. Listen for changes in the sweep itself before attributing every difference to the audio device.

The loudspeaker imposes another deadline

After calculation, samples still have to leave the engine. The manual distinguishes the internal ksmps block from the software output buffer controlled by -b and the device-side buffering associated with -B.[1] A control period of 0.667 milliseconds is therefore not a measurement of total playing latency.

The latency guide treats the settings as a coupled adjustment whose results depend on the platform, hardware, and complexity of the instrument. Smaller buffers reduce room for waiting but leave less tolerance for missed delivery deadlines; glitches reveal when the system cannot keep up.[7] A parameter can move smoothly while the output breaks up, just as stable playback can still feel delayed.

My practical reading is to judge the instrument under its intended load. A solo composer rendering a file can tolerate computation that takes longer than the music's duration. A small performance team needs someone able to rehearse the actual interface and audio setup, including the busiest chord and overlapping release tails. The manual specifically recommends exercising long releases when tuning buffers.[7] A setting that survives one short note has not yet demonstrated that capacity.

The project's 2024 conference photographs place this software among people sharing talks, installations, and musical work.[9] That setting makes its architectural divisions concrete. A score says when a sound should exist. An instrument defines how it changes. The output system must deliver it in time. Csound makes those responsibilities visible enough that a late note, a stepped gesture, and a crackling chord can become three different questions.

cronfeed.work