Developing an Audio Plugin with Remote Control

This module is about building the kind of instrument you can put on stage without a laptop screen: a sampler or synth whose audio core runs headless — on a Raspberry Pi, an Elk board, or inside a DAW — while phones, web pages, hardware knobs, and live-coding environments all drive it over the network. The SOURCE sampler is the running case study, and its architecture is the target skill: state, code, and control designed so the same engine survives every deployment.

The arc starts supported. First you study how a single ValueTree can act as the plugin’s entire state — presets, UI, and in-memory objects all reading one tree — using the XML preset hierarchy (PRESET > SOUND > SOUND_SAMPLE) as a concrete map of state mirroring class structure. Then you practice the specification-first loop: add a row to a CSV parameter schema, regenerate the boilerplate, and watch the parameter appear everywhere at once. This regenerate loop and the message-sending habit (fire an OSC or WebSocket command, observe the state push back) are the two drills worth repeating until automatic, because you will do both dozens of times while building the capstone.

The unsupported step is architectural: splitting engine, sensor I/O, and glue/API into separate processes so the audio thread never touches the network, then exposing a small named-command control plane any client can speak. Every required atom gates that build — drop one and the capstone degrades into a monolith with hand-written parameter plumbing. The supporting atoms enrich rather than gate: sample playback and the MIDI protocol ground what your engine actually renders and receives, while music-centred design sharpens judgment about what your control surface should feel like for performers and audiences.