Slower clocks
Running a node once every N frames — and why running one faster is refused.
Anyone whose LFO is costing as much as their oscillator.
A node can run at a fraction of the graph's rate:
node lfo = Slow / 64;Slow has no idea it was given a different clock, which is the point. Fewer updates can save work for a slowly changing control, but a
held value can still produce audible stepping if it directly drives pitch
or gain.
Holding is the only thing a control value can mean between updates, so / N
needs no policy from you.
What happens between updates?#
The node's last output is held until its next update. At a graph rate of
48 kHz, / 64 runs at 750 Hz, so it changes roughly every 1.33 ms. The node
receives that lower effective sample rate through processor.frequency; a
rate-aware oscillator therefore keeps its intended frequency.
Use a divided clock when the loss of time resolution is acceptable. A slow LFO may be a good candidate; an audio oscillator usually is not. A value that will cause clicks when stepped needs an appropriate smoothing or interpolation stage after the held output.
Try it locally: compare the same modulation source at the full rate and
at / 64, then increase its frequency. Listen for where the held steps become
part of the sound. Current browser execution has limitations for graphs that
cannot use the fused path; check the WebAssembly chapter.
Running a node faster is refused#
* N is rejected, and the diagnostic says why: every edge into and out of an
upsampled node needs a resampling policy — hold, linear, or windowed sinc — and
each has a different latency and a different sound.
That is a design decision, not a missing loop. A language that picked one for you would be making an audible choice silently.