How audio plugins
are actually made
Not a pitch. What is genuinely involved in building one, so you can tell which parts you are skipping and which parts you are not.
Short answer
How are audio plugins made?
A plugin is a small program the DAW loads and hands blocks of audio to, thousands of times a second, with a hard deadline on every block. Traditionally that means C++, a plugin SDK, a build for each platform and code signing before anyone else can run it. All of those steps still happen with Pook — a coding agent does them, and you never see the toolchain.
What the DAW is actually asking for
Your DAW does not hand a plugin a song. It hands it a block of samples — often 128 or 256 of them, a few milliseconds of audio — and asks for the processed block back before the next one is due.
At 48 kHz with a 128-sample buffer, that deadline arrives every 2.7 milliseconds, and it never slips. Miss it and you do not get a slow plugin; you get a click, and then a room full of people looking at the speakers.
Why that makes it different from ordinary software
Most software is allowed to pause. It can wait on a disk, ask the operating system for memory, or take a lock and block until another thread lets go. An audio callback can do none of those things, because any one of them can take longer than the deadline.
That single constraint is what shapes the whole craft. It is why plugin code is written in C++ rather than a language with a garbage collector, why buffers are allocated in advance, and why the interface runs on a completely separate thread from the audio and has to communicate with it carefully.
The part that makes the sound
Inside that callback is the DSP: the arithmetic that turns the incoming samples into the outgoing ones. A filter, a delay line, a compressor’s envelope follower, an oscillator — each is a small, well-understood piece of maths, and the interesting work is in how they are combined and where the deliberate imperfections go.
This is the part with genuine depth. Two compressors doing textbook-identical things sound different because of choices made here, and it is the reason plugin design is a craft rather than a lookup.
The part you look at
The interface is a second program, sharing the plugin with the first. It has to draw itself at any size the DAW asks for, stay in step with parameters the DAW may be automating behind your back, and never block the audio thread while doing it.
Historically this was drawn with the plugin framework’s own graphics layer, which is why so many plugins look like they were built in 2011. Pook runs the interface as HTML, CSS and JavaScript in a native web view, which is a large part of why an authored plugin can look like anything at all.
Turning source into something a DAW will load
Written code is not a plugin. It has to be compiled for each processor architecture, wrapped in each plugin format, packaged into an installer, and signed so that macOS, Windows and Pro Tools will consent to run it.
For a traditional developer this is the least interesting and most time-consuming part of the job: several accounts, two operating systems, and a cycle that has to be repeated for every fix.
Which parts actually changed
Not the DSP — the maths is the same maths, and the real-time deadline has not moved. What changed is who writes it. A coding agent produces the DSP, the interface and the parameter definitions, and Pook removes the rest: it hosts the plugin, handles resizing and delay compensation, exposes the DAW’s transport and tempo, and carries the build and signing toolchain so nothing external is needed.
The judgement is still yours. Deciding that the tail is too long, that the transient is gone, that it flatters the take instead of serving it — no part of that has been automated, and it is the part that was always the actual work.
More questions, answered
Almost always C++, because the audio callback cannot afford an unpredictable pause and C++ leaves memory management to the author. Interfaces are increasingly built with web technology instead, running alongside the audio code rather than inside it.
Because a deadline is missed audibly. A plugin gets a few milliseconds to process each block, and anything that might pause — allocating memory, reading a file, waiting on a lock — is off limits inside that window. Ordinary code is allowed to be occasionally slow; audio code is not.
No. It is here because knowing roughly what is happening makes you better at asking for changes, in the same way knowing what a compressor is doing makes you better at setting one. Nothing on this page is required reading.
It runs as native code under the same real-time rules, so the ceiling is the same. Whether a particular plugin reaches that ceiling depends on how it was written, exactly as it does when a person writes it — an inefficient approach is inefficient either way, and Pook budgets CPU so a heavy one degrades predictably rather than dropping out.
Keep reading
Try it on something of your own.
Pook is free to download and free for 21 days, every feature, no card. Bring your own coding agent and hear the first version in a few minutes.