Debugging and panic recovery in P5LIVE

This module addresses the professional reality of using P5LIVE mid-set: edits go live as you type, but the recompile model has limits that look like bugs, silent canvas failures give no stack trace, and a frozen tab can kill a performance. The ability to read a canvas as a diagnostic display — no exception, no error banner, just the visual result and your knowledge of the failure taxonomy — is what separates a working P5LIVE performer from one who restarts the page.

The arc begins with the recompile boundary, which is the most misunderstood aspect of P5LIVE’s hot-swap model. A softCompile replaces only the edited function body; a hardCompile restarts the entire sketch and resets every global. Knowing this boundary (“editing setup() or a global triggers hardCompile”) determines how to structure performance state: mutable counters, particle arrays, and evolving variables belong inside draw(), not at the global scope. Class-method edits introduce a further wrinkle — old instances keep running the old code until the next hardCompile — so the fix is either to force a re-emit or to avoid stateful class patterns for live-evolving parameters.

From there the module maps the six silent-failure classes. None of these throw a JavaScript exception; diagnosis is purely visual. Missing background() produces trail accumulation — shapes from every prior frame stack on screen. A leaked transform (translate or rotate outside push/pop) drifts or spins faster each frame. Stale class instances show old behaviour despite the edit. Wrong audio-reactivity wiring freezes the reactive parameter at zero with no console complaint, because P5LIVE has three incompatible audio routes (p5.sound, HY5/Hydra bridge, embedded Strudel) and none silently bridges to another. A loadFont() outside preload() silently produces no text. WEBGL mode shifts the canvas origin to center and requires texture() before shapes render colour — broken 2D assumptions fail silently.

The audio-reactivity section requires committing to one route: for p5.sound, call setupAudio(true) in setup and updateAudio() at the top of draw; for HY5, run Hydra with detectAudio:true and read up to 8 bins from a.fft; for embedded Strudel, wire via the .p5live(()=>{}) callback. Using a.fft in P5LIVE without an active Hydra session returns undefined. The HY5 name-clash note is a prerequisite for using Hydra and p5 together: Hydra’s noise() is aliased to noize() inside P5LIVE to avoid collision with p5’s built-in noise().

The capstone exercises all four objectives under no-scaffold conditions. The learner receives a seeded bug file, diagnoses and fixes every silent failure — the six canvas-visible classes plus the frozen-tab loop, the noise/noize clash, the preload/asset trap, the instance-vs-global-mode paste, and a mismatched sandbox/strudel comment region — then restructures global state so the sketch survives live edits, and finally writes the panic recovery skeleton from memory. The annotation requirement forces explicit reasoning: each structural line of the skeleton is labelled with the failure class it prevents. The required audio element confirms one reactivity route is correctly wired and not silently frozen, and the learner must name the route and explain why the other two would read zero in that configuration; the COCODING flag confirms they understand which elements render locally per peer.

The supporting atoms enrich rather than gate. p5js-visual-first-creative-coding frames why P5LIVE suits a performance rig; p5js-push-pop-transformations and p5js-webgl-coordinate-origin provide supplementary reference for the two most common silent failures; p5js-local-server-requirement is a grounding detail for anyone running sketches outside the hosted P5LIVE environment.