How to Make VST Plugins: Languages, Frameworks, Formats and Shipping

To make VST plugins, most developers write C++ using a framework such as JUCE or iPlug2, which handles the plugin formats so you can focus on the audio processing and the interface. You build the project for each format you need (VST3, AU, AAX), sign it, test it in real hosts and with a validator such as pluginval, then package it in an installer.

That's the honest summary. Below is what each step actually involves, what you can skip as a beginner, and the parts of shipping that tutorials tend to leave out.

What is a VST plugin?

A VST plugin is a piece of software that loads inside a DAW and processes or generates audio: an EQ, a compressor, a synth. VST is Steinberg's format; the current version is VST3. Logic Pro and GarageBand use Apple's Audio Units, and Pro Tools uses Avid's AAX. People say "VST" for all of them, but they're separate formats with separate SDKs. Our guide to what a VST plugin is covers the user side; this one is about building them.

What do you need to make a VST plugin?

• C++ knowledge. Not expert level to start, but you'll need to be comfortable with classes, memory and threads.
• A framework. JUCE or iPlug2 for most people. Writing directly against each format's SDK is possible but means repeating the work for every format.
• A compiler and IDE. Xcode on macOS, Visual Studio on Windows. Most frameworks also generate CMake projects.
• Some DSP basics. Sample rates, buffers, decibels, filters. A gain plugin needs almost none; a reverb or synth needs a lot.
• A host to test in. Any DAW works, and frameworks include a lightweight test host for quick iteration.
• For release: an Apple Developer Program membership for macOS signing and notarization, and an Avid developer account if you want AAX.

Which framework should you use?

For a first project, JUCE is the safe choice simply because of how much documentation, example code and community help exists for it. Check its license before you sell anything.

How a plugin is structured: DSP and UI

Every plugin has two halves that run on different threads, and keeping them separate is the most important design rule in plugin development.

• The processor (DSP). The host calls it over and over with a buffer of samples, often a few hundred at a time, and expects the processed buffer back before the deadline. This runs on the real-time audio thread.
• The editor (UI). The window with the knobs. It runs on the main thread, can be opened and closed at any time, and may not exist at all, for example when a session is rendering.
• Parameters connect the two. The UI changes a parameter, the processor reads its current value on the next buffer, and the host can automate it.
• State. The plugin must save and restore its full settings when the host saves a session or a preset.

Plugin formats: VST3, AU and AAX

With a framework, each format is just another build target. The work is in testing them, because hosts load and call plugins in slightly different ways. For where each format installs on disk, see VST vs AU vs AAX.

How to make a VST plugin, step by step

1. Install the tools. Xcode or Visual Studio, CMake, and your framework.
2. Start from a template. JUCE's Projucer or its CMake examples, or iPlug2's example projects, give you a plugin that builds and loads.
3. Write a gain plugin. One parameter, one multiplication per sample. Build it, load it in a DAW, automate it. This proves your whole toolchain works.
4. Add real DSP. A filter, a saturator or a delay. Smooth parameter changes so knob moves don't click, and handle any sample rate and buffer size the host throws at you.
5. Build the interface. Start with the framework's default sliders, then design a custom UI once the sound is right.
6. Save and restore state, and check that automation, presets and session recall all work.
7. Build every format you need, then test each one in real hosts on both operating systems.

Signing and notarization on macOS

Since macOS Catalina, software distributed outside the App Store has to be signed with a Developer ID certificate and notarized by Apple, or Gatekeeper will warn users or refuse to open it. That requires a paid Apple Developer Program membership.

1. Build universal binaries containing both Apple silicon (arm64) and Intel (x86_64) code.
2. Sign each plugin bundle with your Developer ID Application certificate and the hardened runtime enabled.
3. Package an installer and sign it with your Developer ID Installer certificate.
4. Notarize by submitting it to Apple with notarytool, then staple the ticket to the installer so it verifies offline.

On Windows, code signing isn't mandatory, but an unsigned installer triggers SmartScreen warnings that put many users off. AAX adds its own step on both platforms: PACE signing, separate from Apple's.

Testing your plugin

• pluginval. An open-source validator from Tracktion that loads your plugin and runs it through a battery of tests at a strictness level from 1 to 10. Run it on every build.
• Format validators. Steinberg's VST3 SDK includes a validator, and Apple's auval checks Audio Units.
• Real hosts. Test at least in the DAWs your users have: Ableton Live, Logic Pro, FL Studio, Pro Tools, Reaper. Check offline rendering, sample rate changes, odd buffer sizes, automation and session reload.
• Performance. Measure CPU at small buffer sizes and with many instances.

If you want to see what finished plugins in this category look like, our free Pump and Spread are deliberately small: a handful of controls each, built in VST3, AU and AAX. That's a sensible scope for a first commercial plugin too.