Producing with a model in the room
Reading copy. The published version of this note lives on the lab at coconutlabs.org/research/a-model-in-the-room. That copy is canonical.
I make music in Logic, and I am building the instrument I make it with: a synthesizer plugin, codename syn1, written in C++ as an Audio Unit. There is a model in the room for almost all of it. Not composing. That is exactly where I have learned to keep it out. But present three distinct ways, and after months of build logs I can name all three precisely instead of gesturing at vibes.
Job one: bench partner on the instrument itself
The synth is real engineering: a JUCE plugin wrapped around a DSP core that deliberately has no JUCE in it, so the whole test suite runs against a small test framework in seconds instead of compiling against a gigabyte of framework. The model earns its seat here the way a sharp pairing partner does: DSP math, test design, build systems, the unglamorous parts.
Two scars from the build log show the texture of that work. One: the build has a switch to not install the freshly built plugin, because swapping a component under a live Logic session can take the session down. I learned that the loud way. Two: each build directory fetches its own dependencies, because six parallel workers racing to fill one shared cache corrupt it. Neither insight is about music. Both decide whether the instrument ships.
Job two: inside the instrument, behind a fence
The plugin itself has a harmony assistant, a mood pad, and a generate panel. Which sounds like I broke my own rule, so here is the fence. Those features propose: candidate chords under a melody, parameter neighborhoods that match a mood, phrases to audition. Proposals arrive as options you scroll through with your hands on the keys. Nothing lands in the track without a human committing it. The model expands the menu. It never orders for you.
Building it this way settled an argument I used to have in the abstract: the useful place for a model in a creative tool is upstream of the decision, widening what you consider, never downstream of it, narrowing what you keep. Every feature that respected that line got used. The one prototype that did not respect it produced parts that were competent and dead, the average of everything, which is the one thing a track must never be.
Job three: study tool for borrowed ears
I also built a small localhost tool that takes a track and gives me back six separated stems and a beat grid I can scrub, solo, and mute. It is how I study arrangements I admire: isolate the bass, loop four bars, hear the trick. On Apple Silicon the separation runs on the GPU, measured about 32 times faster than CPU with numerically identical output. Nothing leaves the machine. It is reference listening with the lid off.
The takeaway
Keep the model in the room and out of the chair. Let it build with you, let it widen the menu, let it lend you ears when yours are tired. The choices stay human, and in my patch library you can hear exactly where that boundary runs. It is the same discipline this whole site keeps circling: tools one level down, judgment kept on top.