UGens run at audio rate (.ar) or control rate (.kr), trading CPU for update resolution; only .ar signals reach the speakers

Every UGen is instantiated by sending it .ar (audio rate) or .kr (control rate). An audio-rate UGen computes one value per output sample — typically 44,100 per second — and can be sent to audio output. A control-rate UGen computes a single value per control block (block size 64 samples by default), yielding about 689 values/sec at 1/64th the CPU cost. Control-rate output does not go to the loudspeaker; it modulates parameters of other UGens, and a .kr signal feeding an .ar input is smoothly interpolated by SC. The convention: use .ar for audible signals (oscillators, filters) and .kr for slow-moving controls (LFOs, envelopes), and mix them freely — a .kr LFO can modulate an .ar oscillator. Almost every UGen also takes mul and add (which scale then offset the output and may themselves be signals), making modulation connections concise. The .poll method samples any UGen’s output ~10 times/sec into the Post window for inspection. Choosing .kr where resolution is not needed can save large amounts of CPU across many voices; audio-rate signals are kept only where per-sample accuracy matters.

Examples

{SinOsc.ar(440)}.play;                 // audio → speaker
{SinOsc.kr(1).poll}.play;              // control → Post window only, no sound
{SinOsc.ar(freq: MouseX.kr(300,2500), mul:0.1)}.play; // .kr controlling .ar
{ SinOsc.ar(LFNoise1.kr(4).range(200,800), 0, 0.3) }.play; // kr LFO on ar osc

Assessment

Explain why {SinOsc.kr(440)}.play makes no audible sound and give the approximate sample rate of a control-rate UGen. For each case say .ar or .kr: an oscillator heard as a tone; a slow LFO on filter cutoff; mouse position controlling frequency. Then name one case where an LFO must run at .ar for correctness.