home/ atoms/ clock-quantized-launch-explicit

In imperative engines, clock-quantized launch must be explicitly coded; Strudel/Tidal get it implicitly from the global cycle clock

Clock-quantized launch delays a voice’s start until the next boundary of a shared grid so independently-added parts lock in phase (Ableton-style quantized launch). In cyclic pattern engines like Strudel and Tidal, this is automatic: any new pattern always starts at the next cycle boundary because the global clock drives all patterns. In imperative engines (ChucK, Sonic Pi, SuperCollider), there is no shared cycle clock, so quantized launch must be explicitly implemented: ChucK uses T - (now % T) => now, SuperCollider uses .play(quant:4), Sonic Pi uses sync. This is a practical gotcha: in imperative engines, two voices started at different code-execution times will be phase-offset unless quantized launch is coded explicitly.

Examples

ChucK: float T = 1.0; (T - (now % T)) => now; — wait until next beat boundary. SuperCollider: Pdef(‘voice1’).play(quant: [4, 0]).

Assessment

Explain why Strudel users never need to think about quantized launch but ChucK users do. Write pseudocode for a ChucK quantized launch that waits for the next bar boundary.

“Strudel/Tidal get this **implicitly** from the global cycle clock (you never ask for it); imperative engines make it an explicit, per-voice act.”
context/ · L2-composer/music/time-and-concurrency.md · chunk 1