Make hardware instruments behave like plugins. A Raspberry Pi 4B plays as an instrument track in Ableton Live today — Git-style total recall through the project’s own save/reopen, knobs as sample-accurate automation lanes, and offline bounce through the physical box.

Hardware synths, drum machines, and effects have connected to computers for forty years, and the connection is still fragile in one specific way: recall. Audio mostly works, MIDI mostly works — but reopen last month’s project and the hardware is not in the state you saved, and nothing will tell you. The deep integrations that fix this (multichannel USB audio, plugin-shell control, total recall) have existed only inside closed single-vendor ecosystems, because every vendor has to rebuild drivers, state sync, and DAW compatibility from scratch.

HARP is a complete, working implementation of that integration — with an open spec underneath, if you want to build a device on it. The reference device is a Raspberry Pi running a 16-part multitimbral, 8-voice-polyphonic synth (13 params per part); anything that speaks the protocol gets the same treatment from any conforming host:

• Total recall, Git-style — device state is content-addressed and hash-verified; a saved project reopens with the hardware provably in the saved state, every overwrite preceded by a free snapshot, every mismatch resolved through explicit safe actions — never silently. The archive doubles as patch time-travel: every state the box has ever been pushed over is one click away.
• Audio as a plugin — a dedicated stream into the plugin shell that bypasses the OS audio stack (no aggregate-device hacks), including a host-paced mode where the hardware renders deterministically, byte- identical, faster than real time: offline bounce through a physical box at ~25× real time, with 16 ms of reported latency at DAW buffers ≤ 256 — in the neighborhood of a good audio interface.
• Multitimbral, addressed like plugins — one physical device is one session, and several shell instances can share it: drop the plugin on a handful of DAW tracks and each instance drives its own part — its own channel, params, recall state, and stereo output (16 parts, with a summed main mix alongside the per-part outputs). A recall-safe Part knob persists each track’s part in the project, and that per-part state moves intact between the VST3 and AU formats (the CLAP shell writes the same recall bundle).
• Polyphonic, with per-voice modulation — each part is an 8-voice pool with deterministic voice allocation, so overlapping notes ring out on their own voices instead of stealing one. Modulation is non-destructive and per voice: a VST3 Note Expression or a CLAP per-note parameter modulation bends a single sounding note’s filter cutoff without touching the stored patch — and the two formats render byte-identically (the device applies the §9.5 mod the same regardless of which shell sent it).
• Sample-accurate everything — DAW automation becomes device-interpolated ramps applied within ±1 sample; notes travel as UMP; an event fence makes “applied late” structurally impossible rather than statistically rare. Turn a knob on the hardware and the DAW records the automation (echo).
• Musical time — devices follow the DAW’s transport: tempo, position, loops. The reference device’s arpeggiator locks to Live’s grid sample-exactly, survives loop wraps, and renders a byte-identical groove — determinism extended to musical time.
• Identity, timing, diagnostics — engine versioning and parameter-map hashing protect old songs from new firmware, latency is measured (never guessed), and error counters at every layer end “it glitched” support threads with evidence.
• Roadie-proof sessions — unplug the cable mid-song and plug it back: the shell reconnects, re-asserts the project’s state, and audio resumes. Hostile or corrupt wire input ends in a clean session reset, never a crash (every parser is fuzzed; a live abuse test is part of CI).

github.com/kschzt/harp