Live coding as a performance practice

This module turns “I can make my editor beep” into a first real performance. The whole task is a three-minute improvisation from an empty buffer, played for one actual listener — the smallest honest version of what happens at an algorave or TOPLAP-style gig, where the screen is projected and the audience watches the set being written. Any environment you already have running (Tidal/Strudel, Sonic Pi, Glicol, SuperCollider) is enough rig; the point is the practice, not the tool.

The arc starts private and supported. First, rehearse the perception loop deliberately: before every evaluation, use the predict-imagine-run-diagnose cycle (imagine the sound before pressing Run) and say out loud what you expect versus what you hear. That drill makes the write → run → listen → respond cycle articulate, so narrating it live later is describing something you actually do. Next, do timed blank-slate sketches with no audience, leaning on the process-first stance — start from a seed and follow where it leads — and on the map/territory idea that you cannot read your code until you run it. Finally, add the witness: performing for one listener while thinking aloud is the unsupported capstone, a miniature of code projection making thinking public.

The required atoms are exactly what the capstone cannot be done well without: the feedback-loop concepts gate the narration, the blank-slate, process-over-plan, and improvised-versus-pre-prepared spectrum atoms gate both the performance constraint and the written reflection, and the performance, improvising-composer, and thinking-in-public framings gate playing for a witness at all. The supporting atoms enrich rather than gate — crash culture, notation theory, instrument-versus-DAW directness, scene history, and tool-landscape context that deepen the reflection but are not needed to complete it.