NKIDO

Live coding means editing the program while it is making sound in front of an audience. The audio callback gets 2.67 ms to produce the next block and cannot wait for a memory allocator, a garbage collector or a lock. And when the performer hits evaluate, the new version has to take over without a click, a gap, or a filter snapping back to zero.

Then the same engine has to run in five places that agree on nothing: a browser tab, a desktop app, a plugin inside somebody's DAW, a game engine, and a microcontroller.

Two pieces, cleanly split. Akkado is the language, Strudel/Tidal-style mini-notation over a functional graph, compiled through a lexer, a Pratt parser, an AST, a DAG and a topological sort into bytecode. Cedar is the runtime: a stack-based VM with 95+ opcodes executing 128-sample blocks and allocating nothing once it is running. Everything the audio thread needs exists before the audio thread starts.

Hot-swap is the interesting part. Nodes carry semantic IDs, so when new bytecode arrives the VM matches state from the old graph onto the new one. An oscillator that survived the edit keeps its phase, a filter keeps its history, and a 5–10 ms micro-crossfade covers whatever genuinely changed. The performer hears the edit, not the reload.

Portability comes from keeping the engine as plain C++20 with no host assumptions: Emscripten for the browser IDE, JUCE for the DAW and plugin formats, a GDExtension for Godot, and a bare ESP32-P4 build for the hardware groovebox.

The engine and the browser IDE are shipping; the plugin and the hardware are in build. The compiler and the VM are the same code in every target, which is what keeps five very different runtimes a distribution problem instead of five products.