Sonic Pi: concurrent live_loops and sync
Learning objectives
- learner can run multiple live_loops as concurrent threads without duplicate-instance bugs
- learner can phase-align loops with cue/sync and Time State
- learner can redefine named functions live to restructure a running piece
Capstone — one whole task that evidences the objectives
Live-code a Sonic Pi set with three concurrent named live_loops kept in phase via cue/sync and Time State, and restructure it mid-performance by redefining a function without stopping the audio.
Prerequisite modules
A real Sonic Pi set — the kind you’d play at an algorave or stream from a bedroom rig — is never one loop. It is a drum part, a bassline, and a melodic layer running at once, staying locked to a shared groove while you rewrite the music underneath the audience’s feet. This module builds exactly that skill: keeping three concurrent voices in phase and restructuring the piece live, with the audio never stopping.
The arc starts from the beginner’s wall: writing two infinite loops in sequence and hearing only the first. Understanding why sequential loops fail motivates everything after. From there, a first supported exercise layers parts with “in_thread do … end launches a concurrent execution path” and discovers the Run-button mechanic — each press adds a thread rather than restarting. That immediately exposes the duplicate-instance trap, solved by named threads, which are also the conceptual bridge to live_loop’s hot-swap behaviour. A second exercise deliberately lets two loops drift, then repairs them using “cue broadcasts a named event and sync blocks until the next occurrence” and the auto-generated cue events every live_loop emits. Time State (get/set) then replaces fragile shared variables so loops can coordinate deterministically. Finally, the define/redefine pattern — swap a function’s body while a loop keeps calling it — gives you live restructuring.
The required atoms gate the capstone directly: you cannot run three loops, phase-align them, or hot-swap a function without them, and the drills (cue/sync, loop-to-loop sync, redefine-while-running) must be automatic under performance pressure. Supporting atoms enrich the same territory — the race-condition misconception explains why Time State exists, Reich-style phasing turns drift into an aesthetic, control of SynthNode references enables post-trigger parameter gestures, and the MIDI/OSC atoms extend sync to external hardware for a bigger rig.
Runnable examples
Generated from the context/ instrument corpus by concept (redistributable idioms only). Do not edit — regenerate with gen-module-examples.mjs.
live-hot-swap
live_loop :x do; play 60; sleep 1; end
sonicpi-0048 · CC0
Ndef(\a, { SinOsc.ar(220) * 0.1 }).play
supercollider-0037 · CC0
event-driven-sync
live_loop :hats, sync: :tick do; sample :drum_cymbal_closed; sleep 0.25; end
sonicpi-0049 · CC0
Event e; fun void hit(){ e => now; <<<"go">>>; }
spork ~ hit(); spork ~ hit(); 1::ms => now; e.broadcast();
chuck-0014 · MIT
Atoms in this module
Required — these gate the capstone
Supporting — enrichment, not gating
Part of curricula
- Live Coder — zero to performing live-coded music — Generative Systems & the SuperCollider Stack optional