First sketches: the p5.js/Processing drawing core

This module is where visuals for a live set stop being someone else’s demo and become something you can build on a blank canvas. In an audio-visual live-coding rig, p5.js or Processing is typically the projection layer: a sketch running fullscreen next to your sound engine, redrawing sixty times a second, its parameters ready to be wired to amplitude or MIDI later. Before any of that reactivity is possible, you need the drawing core — and that is the whole task here: an animated generative composition that fills the screen, varies itself, and never freezes the frame loop.

The arc starts fully supported. First exercises are static: place primitives on the canvas using the top-left-origin coordinate system, styling them with fill/stroke state (“Processing separates fill, stroke, and strokeWeight into independent state settings” is your JIT pointer when a shape inherits the wrong colour). Then motion enters via the two lifecycle functions — “setup() runs once and draw() runs every frame” — and a single variable nudged each frame. From there, scaffolding drops away: a for-loop turns one shape into a grid, conditionals make cells diverge, and “p5.js map() rescales a value from one numeric range into another” converts loop counters into RGB channels.

The required atoms gate the capstone directly: without setup/draw there is no animation, without loops no grid, without map() no parameterised colour. Supporting atoms enrich rather than gate — the frame-loop procedure atom deepens the same setup/draw material with frameRate() and trail effects, variable scope explains the classic frozen-animation bug, HSB colour modes and custom functions point toward cleaner, more expressive sketches, and the abstraction principle frames why one call can draw so much.