Lovable, but for audio plugins

People describe Sonorie as “Lovable, but for audio plugins”, and it is a good shorthand. Both replace a blank editor with a conversation: you say what you want, something real comes back, and you change it by saying what is wrong. That loop is the product in both cases.

It is worth taking the comparison seriously, though, because where it breaks is exactly where the interesting engineering is.

What carries over

The valuable part of chat-built software is not that a model writes code. It is that the distance between an idea and a working version of it collapses to about a minute, so you stop planning and start listening. A plugin idea is usually vague — “a warm tape echo that darkens as it repeats” — and vague ideas are exactly the ones you cannot evaluate on paper. You have to hear them.

So the shape is identical: describe, hear, refine. Ask for a delay, get a delay, say “more wobble, darker repeats”, hear it again. Nothing about that requires you to know what a biquad is, which is the whole point.

Where it breaks, part one: the audio thread

A web app that stalls for 50 milliseconds feels slow. An audio callback that stalls for 50 milliseconds is a click, and everyone in the room hears it. The callback runs a few thousand times a second on a thread that is not allowed to allocate memory, take a lock, touch a file or wait for anything at all.

That is a real constraint on generated code, and it cannot be checked by reading. Every plugin Sonorie generates is compiled and then measured: its frequency response, its harmonic content, its latency, its loudness change, the aliasing it produces on a hot signal. A compressor that claims 4:1 is driven with a test signal to see whether it actually compresses 4:1. Code that allocates inside its process loop is rejected before you ever hear it.

Nothing in a website generator needs that machinery, because a page that renders is a page that works. An effect that makes sound is not necessarily an effect that works.

Where it breaks, part two: it has to be a binary

The other difference is what you walk away with. A generated web app lives on a URL. A plugin has to load inside Ableton, Logic, FL Studio or REAPER — programs written years ago in C++ that will load a shared library and nothing else.

So Sonorie compiles the same source twice. Once to WebAssembly, which is what you hear in the browser while you are working. Once to native code, through a build farm, producing a real VST3, AU, CLAP and LV2 plus a standalone application, for Windows, macOS and Linux.

Because both come from one source, the preview is not a mock-up of the plugin. It is the plugin, running somewhere else.

The part nobody asks about

There is a third difference, and it is the one that shaped the project most. Plugin frameworks are licensed software, and the usual licences do not allow you to build a service that generates products with them. Sonorie therefore has its own framework — a header-only C++17 library that implements the plugin formats directly, with its own DSP toolkit written from the published maths rather than adapted from anybody’s source.

That was a much larger undertaking than the chat interface, and it is why the plugins you export are yours with no third-party runtime attached. It has its own story, which is written up separately.

So: is it Lovable for audio plugins?

For what you do, yes — describe, hear, refine, export. For what it takes to make that true, not really: the web version of this idea can trust the browser to run whatever it is given, and an audio version has to prove that what it generated is real-time safe, measure that it does what it claims, and compile it into five formats on three operating systems.

The good news is that none of that is your problem. You describe an effect, and a minute later you are listening to it.