Why build a DAW
A research audit of the shipping workstations found that none of them is agent-native. REAPER, FL Studio, Bitwig, Ableton Live, Logic Pro, Studio One and Cubase all keep the project inside a GUI: none has a headless mode or exposes its undo history as data, and the “DAW control” servers of the last two years are scripts proxying a window. FL Studio in particular turned out to be a dead end for reading project state.
So the lab built one around a single test, asked both ways: if the window disappeared, could an agent still make music? And if the agents disappeared, would a musician still have a workstation? Both have to be true, on the same project, at the same time.
How it works
- One engine, two drivers. A C++ engine on JUCE and Tracktion Engine is the authority. A person drives it through the Warlock DAW window; an agent drives it over a local WebSocket (JSON-RPC) or MCP. Neither is a second-class citizen.
- Every edit is a receipt. Receipts are hash-chained, human and agent edits interleave in one chain, and either side can verify the other’s history.
- Projects are versioned like code. Commit, branch, check out, roll back, compare, preview a merge.
- The reference instrument is DUNE 3. 1,700 patches were catalogued and 1,699 load without a window.
What was built
| Phase | What | Gate |
|---|---|---|
| 0 | Research audit and headless probes | A dossier with a build order |
| 1 | Patch catalogue, project model, commands with receipts, headless render, loudness and spectrum analysis | 1,699 of 1,700 patches load; proof steps 1 to 10 pass |
| 2 | Commits, branches, rollback, compare, merge preview, automation rendering, reproducibility | Proof steps 11 to 15 and a two-run reproducibility check pass |
| 3 | Two engine spikes, plain JUCE against Tracktion | Both open the project and render within tolerance; Tracktion chosen |
| 4 | The authoritative engine: sessions, receipted transactions, undo and redo, render and transport | The Phase 1 and 2 agent script runs unchanged over the socket, 10 of 10 |
| 5 | Audio tracks, buses, sends, built-in effects, freeze, meters, recording | 24 of 24, plus a live vocal take recorded into an armed track while the arrangement played |
| 6 | The Warlock DAW window: transport with branch switcher, arrangement, piano roll, mixer with live meters, plugin windows, a receipt panel | 5 of 5, with an agent running its full script against the open window |
All six phases were built and gated on 16 September 2026.
What the gates caught
The best catch was not a test. Listening to a render, the ear caught DUNE’s arpeggiator re-sequencing the bass line, a defect 32 green tests had missed. It became a contract item: patches now report their sequencer state, and tools switch it off before note-driven work. Renders are compared by analysis (loudness, true peak, spectral centroid within tolerance), never by file hash, because the synth is not bit-deterministic.
Honest limits
- Local and Windows-only; setup needs a licensed DUNE 3. Not released.
- No live fader riding or automation recording while the transport rolls; the recording UX (input monitoring, punch-in, take comping) is shallow.
- A clean-clone build sweep of every target is still owed before it can be called shippable.
- Phase 7 (automation lanes, quantise, humanise, note probability) is being built now and has not passed its gate.
Where it is going
Phase 8 wraps the engine for Baby Warlock: commands under JobAuthority, receipts mirrored, destructive operations behind approval. After that, plugin hosting and process isolation. The Dark Choir cast is being folded in as the vocal stem producer. The goal for the page’s last line: say “make me a darker version of this with more filter movement”, watch a branch appear, hear both, keep one, and always know what changed and how to take it back.
Sub-projects
Inside Warlock DAW
Field reports