Sonic Pi: debugging common errors and recovering under pressure

A Sonic Pi live session fails differently from a normal program: errors can silence one loop while the rest keep playing, a bad synth name can just drop to silence with no log entry, and a sync on the wrong tag blocks a thread forever without surfacing anything readable. On a stage or in a stream, these failures arrive with no time to google. This module is the systematic inoculation — you encounter every common error in a safe drill context first, so your hands know the fix before a performance demands it.

The arc is deliberately adversarial. Each exercise hands you broken code, asks you to read the log (or notice the silence), identify the cause from the atom that governs it, and apply the minimal fix — no restarting the buffer, keeping the other loops running throughout. The first cluster covers the live_loop lifecycle: “A live_loop with no sleep throws a did-not-sleep error and stops” and its twin-misconception atom (“Every Sonic Pi live_loop body must call sleep or sync or it stops”) establish that sleep or sync is not optional. These two atoms look similar but address complementary failure modes — the first is L1 gotcha-recognition, the second is the L5 internalized rule — and both must be reflexive. Alongside them, duplicate-name replacement and buffer-reeval swap-at-boundary are the two mechanics that surprise every programmer who treats Sonic Pi like a script runner rather than a live instrument.

The second cluster is naming and symbols. Sonic Pi has a closed synth/sample/fx namespace — :kick, :bass, :verb are all errors — and the real names (:bd_haus, :tb303, :reverb) must be drilled until they are rote. The symbols-not-strings misconception (play "e3" silently doing nothing vs play :e3) is the single most common beginner error across every tutorial channel. Both atoms belong in the required set because the capstone explicitly tests them.

The concurrency cluster forms the third arc. sync on a tag that never fires blocks the loop forever without error — the sync-deadlock atom is the single most dangerous Silence Trap in Sonic Pi, because you have no log to read. use_bpm being thread-local is the subtler cousin: the loop reads right, sounds wrong, and nothing errors. with_fx block scope — only sounds inside the do...end go through the effect — trips up everyone who writes the fx header above a loop body rather than around it. These three traps require separate minimal reproductions in the drills; do not batch them.

The control/modulation cluster (control-needs-handle and control-node-lifecycle) is the gateway to expressive live parameter gestures. The key insight is that a synth node is a one-time allocated voice: to automate it later, you must capture its return value at creation, set the matching *_slide opt before calling control, and ensure the node is still alive (long sustain: or an fx handle). Without all three conditions, control silently does nothing.

The capstone synthesises all of this into a session that has been broken and repaired from every angle. The panic-fallback drill is the non-negotiable close: write a minimal always-valid groove from memory — :bd_haus kick loop, :saw bass with sync:, use_bpm once at top — and deploy it under a simulated crisis. Internalise that fallback as your safety net, not a last resort.

Supporting atoms enrich rather than gate: sonicpi-sleep-in-beats grounds the BPM unit confusion, sonicpi-range-excludes-end and sonicpi-tick-vs-look are the off-by-one cluster that supplements ring-indexing once the live-loop mechanics are solid, sonicpi-runaway-feedback-level explains the one audio hazard that produces no error (feedback clipping), and sonicpi-live-loop-auto-cues-own-name illuminates why sync: :loop_name works without explicit cues — clarifying the sync-deadlock atom’s boundary condition. sonicpi-not-in-rig is a one-read reference: Sonic Pi has no FFT bridge to the rig’s Hydra layer, so audio-reactive visuals require Strudel instead — file it and move on.