Audio Plugins

0What is an audio plugin?

An audio plugin is a self-contained software module that a host application loads at run time to process or generate audio. The host — usually a digital audio workstation (DAW) such as Ableton Live, Logic Pro, Cubase, Pro Tools, or Reaper — owns the audio hardware, the transport, and the mix graph; the plugin is dropped into that graph to do one job: filter a signal, squeeze its dynamics, drench it in reverberation, or synthesise notes from MIDI.

Conceptually a plugin is a function evaluated on a stream of samples. The host hands it a small block of input samples together with the current parameter values, and the plugin returns a block of output samples. An effect maps audio in to audio out; an instrument maps MIDI in to audio out. Everything else — the knobs, the meters, the saved presets — is machinery around that central mapping.

A typical insert chain: plugins process the signal in series, each feeding the next.

Two facts shape everything about how plugins are written. First, they run on the real-time audio thread: the host calls the plugin's process function every few milliseconds, and it must always finish before the soundcard needs the next buffer or the listener hears a click. That callback may not lock a mutex, allocate memory, touch a file, or block on anything — the discipline that governs all serious audio code. Second, the plugin must conform to a format: a binary and API contract (VST3, Audio Unit, AAX, CLAP…) that tells the host how to find it, negotiate its buses, enumerate its parameters, and call it safely.

Try it — a plugin is just f(x)

Below, a short loop is synthesised in your browser and passed through a trivial "plugin" — a one-knob tilt filter with a bypass. This is the whole idea in miniature: a source, a processor with a parameter, and an A/B comparison. The seven example repositories at the end build the real thing for each effect family.

All audio on this site is generated or processed live in the browser with the Web Audio API — nothing is streamed from a file. It is a faithful analogue of what a native plugin does inside a DAW, running on the same principles.

1A short history

The plugin is the child of two older worlds colliding: the rack of outboard studio hardware, and the general-purpose computer fast enough to emulate it in real time.

For most of the twentieth century, signal processing meant hardware: passive Pultec equalisers, optical LA-2A compressors, EMT plate reverbs, tape echoes, and Moog modular synthesisers — each a physical box patched into the console. Digital signal processing arrived in studios first as expensive dedicated hardware (the Lexicon 224, the Publison and AMS units, the Sony DRE) and then, in the late 1980s, as DSP-card systems: Digidesign's Sound Tools and then Pro Tools ran effects on Motorola 56000 chips mounted inside the computer. The processing was still on custom silicon, but the routing and the user interface had moved into software.

The decisive break came in 1996, when Steinberg opened the Virtual Studio Technology (VST) interface in Cubase and — crucially — published the SDK so that anyone could write an effect that ran on the host CPU. Native processing, an open API, and ever-faster processors turned a specialist hardware market into a software one. Within a decade the mixing desk, the outboard rack, and the synthesiser had all been redrawn as windows on a screen.

The plugin did to the recording studio what the spreadsheet did to the accountant's desk: it did not merely digitise the tools, it dissolved the boundary between the tool and the workspace, so that an unlimited rack could be conjured and rearranged at will.

2Formats — the technologies that carry a plugin

A format is the contract between plugin and host: how the binary is packaged, how the host discovers and instantiates it, how buses and parameters are described, and how the process callback is invoked. Choosing which to support is the first engineering decision; most developers target several through one framework.

Beneath the differences, every format exposes the same handful of ideas: a way to enumerate parameters (with ranges, units, and automation), a bus layout (mono/stereo/side-chain in and out), a process callback operating on sample blocks, and a mechanism to save and restore state so a session recalls exactly what you heard. A good framework hides the format-specific plumbing behind one API, so you write the DSP once and it compiles to VST3, AU, AAX, CLAP and Standalone together.

3The types commonly built

Almost every plugin falls into one of a dozen families. The seven with a green arrow have a full working example in this collection — click through to play them.

Effects — process audio in

Instruments — generate audio from MIDI

MIDI & control

4Anatomy of a plugin

Whatever the format or framework, a plugin has the same four parts. Understanding the boundaries between them — especially the wall between the audio thread and everything else — is the whole craft.

The real-time contract

The audio callback runs under a hard deadline. With a 48 kHz sample rate and a 128-sample buffer, the host expects the next block roughly every $128/48000 \approx 2.67$ ms, forever, without exception. Miss it and the listener hears a click or dropout. The rules that follow are absolute inside the callback:

• No memory allocation — new/malloc can block on the OS. Pre-allocate everything in prepareToPlay.
• No locks — a mutex held by a lower-priority thread can cause priority inversion and a glitch. Communicate with lock-free FIFOs and atomics.
• No system calls — no file, network, or console I/O; no unbounded loops.
• Bounded, deterministic work — the cost of a block must not depend on data in ways that can spike.

Everything the DSP does — every biquad, every delay tap, every oscillator — is a small, predictable amount of arithmetic chosen to fit comfortably inside that window even with dozens of instances running at once.

5Frameworks — how plugins are actually built

Nobody writes VST3, AU, AAX and CLAP boilerplate by hand for each product. A framework provides the format wrappers, a DSP library, a GUI toolkit, and a build system, so you write the plugin once and export to all targets.

*CLAP support in JUCE is available via the community clap-juce-extensions.

For nearly all newcomers the answer is JUCE: it has the largest community, the most complete DSP and GUI libraries, and it targets every mainstream format from a single C++ codebase. This collection includes a dedicated in-depth JUCE tutorial, and every example plugin below shows its DSP written both in browser JavaScript (so you can hear it here) and in idiomatic JUCE C++ (so you can build it for real).

6The DSP building blocks

A surprisingly small toolbox of primitives, combined and tuned, produces the entire catalogue of effects and instruments. Each links to the example where it does the work.

The sample loop

At bottom, all of it is a loop over samples. A processor keeps some state (past inputs and outputs, buffer contents, oscillator phase) and, for each incoming sample $x[n]$, emits $y[n]$ as a function of the input and that state. A linear time-invariant block is fully described by a difference equation:

whose behaviour is captured by the transfer function $H(z) = \dfrac{\sum_k b_k z^{-k}}{1+\sum_k a_k z^{-k}}$, evaluated on the unit circle $z=e^{j\omega}$ to read off the frequency response. From this one relation flow filters, equalisers, comb-based delays and reverbs.

7Building & shipping

A plugin is a product as much as a program. Turning working DSP into something that loads reliably in every host on every machine is its own discipline.

• Build system. Modern JUCE uses CMake to produce all targets; the classic route is the Projucer. A CI matrix cross-compiles for Windows, macOS (universal x86-64 + arm64), and Linux.
• Validation. Apple's auval gates AU loading; the community's pluginval stress-tests VST3/AU/AAX against threading, state, and bus-layout edge cases. Passing them is non-negotiable before release.
• Code signing & notarisation. macOS requires signed, notarised, hardened-runtime binaries or Gatekeeper blocks them; Windows expects an Authenticode signature. AAX additionally requires Avid's PACE signing.
• Installers. Plugins live in fixed folders (~/Library/Audio/Plug-Ins/… on macOS, %CommonProgramFiles%\VST3 on Windows). Installers place each format's bundle correctly and clean up old versions.
• Licensing & protection. From simple serials to challenge–response and third-party systems; the perennial tension between piracy resistance and user goodwill.
• Latency reporting. Any look-ahead or oversampling introduces delay; the plugin must report its latency so the host can compensate and keep tracks in sync.

8The collection

Nine repositories. This hub, an in-depth JUCE tutorial, and seven working plugin examples — each a self-contained page with a live, playable demo, real DSP maths, and the equivalent JUCE C++.