Creating VST Plugins

One of SynthEdit’s most powerful features is the ability to export your projects as standalone VST3 plugins. These plugins work in any DAW that supports the VST3 format.

A patch like this — MIDI In → Patch Automator → voice modules → Voice Combiner → Sound Out — is the typical shape of a VST instrument before export. The Patch Automator is what exposes your panel controls to the host DAW as automatable parameters.

Designing the GUI

Before exporting, you’ll want to create a user interface for your plugin:

1. Switch to the Panel view
2. Add controls — knobs, sliders, switches, labels
3. Connect controls to module parameters
4. Customize the appearance with colors, images, and layout

The panel’s size becomes the plugin window’s size. If you want the user to be able to scale that window up or down inside the DAW, see Resizable Plugin Windows.

Exporting as VST3

1. Go to File > Export VST Plugin
2. Choose a location to save the plugin
3. Set the plugin name, manufacturer, and unique ID
4. Click Export

SynthEdit generates a .vst3 file that you can install in your DAW’s plugin folder.

Including Audio, MIDI and SoundFont Files

If your project uses external files — a sample loaded by a Wave Player, a MIDI file driving a MIDI Player, a SoundFont — those files need to ship inside the exported plugin too. SynthEdit looks for them in a folder next to your project named <project-name>.resources.

For example, if your project is MySynth.synthedit, create a folder called MySynth.resources alongside it and drop your .wav, .mid, .sf2, etc. files in there. When you pick one of those files in a module’s File Name pin, SynthEdit will find it in .resources/ first, then fall back to your global Audio / MIDI / SoundFont folders set in Preferences.

On export, the entire .resources folder is copied verbatim into the exported VST3 / AU bundle’s Resources folder. The plugin finds the files at runtime by the same short filename, so the patch just works in any DAW on any machine.

Why a dedicated folder?

Skin images and font assets get exported automatically — SynthEdit displays your GUI during export, which forces every panel control to register the images it needs. Audio, MIDI and SoundFont files can’t be discovered the same way (the audio engine doesn’t necessarily run during export), so putting them in .resources is the reliable way to make sure they travel with the plugin.

Testing Your Plugin

1. Copy the .vst3 file to your system’s VST3 folder
2. Rescan plugins in your DAW
3. Load the plugin on a track
4. Test all controls and audio processing

Code-signing and notarization on macOS

Before you share a macOS plugin with anyone else, it has to be code-signed and notarized. This applies to both the Audio Unit (.component) and the macOS VST3 — it isn’t optional, and it isn’t something SynthEdit can do for you.

SynthEdit signs exported plugins so they run on your own machine while you’re developing. That signature is not enough for distribution. Once a file has been downloaded — from your website, a mailing list, anywhere — macOS attaches a quarantine flag, and Gatekeeper refuses to load anything that isn’t signed with a Developer ID Application certificate and notarized by Apple. For an Audio Unit the failure is especially unhelpful: sandboxed hosts like Logic Pro and GarageBand simply won’t list your plugin, with no error explaining why. auval may pass on your machine and still fail on your customer’s.

What’s involved:

1. Join the Apple Developer Program (currently US$99/year) and create a Developer ID Application certificate. There’s no free path to a distributable macOS plugin.
2. Sign each bundle with that certificate, using the hardened runtime (--options runtime) and a secure timestamp (--timestamp). Sign everything inside the bundle too — see below.
3. Notarize — upload the signed plugin (usually wrapped in a .pkg installer or .dmg) to Apple with notarytool. Apple scans it and returns a ticket.
4. Staple the ticket to the installer with stapler, so it validates even offline.

Sign the embedded modules too, from the inside out

An exported plugin isn’t a single binary. Any third-party modules your patch uses are copied into the exported .vst3 / .component, and on macOS each one is its own bundle with its own executable. Every one of those is code, and macOS validates all of it.

Signing only the outer bundle is the most common way to get a plugin that works perfectly on your machine and is rejected on everyone else’s — the outer signature is valid, notarization fails or Gatekeeper rejects the load because a nested binary is unsigned or signed with the wrong identity.

Sign inside out: every nested bundle, framework and dylib first, then the outer plugin bundle last. Each nested item needs the same certificate, hardened runtime and timestamp as the outer one. Signing the outer bundle first and the nested code afterwards invalidates the outer signature, so the order matters.

A note on codesign --deep: it looks like the shortcut for exactly this, and Apple recommends against using it to sign — it applies one set of options to everything it signs (nested code often needs different entitlements), and it only finds nested code where the system expects code, so anything tucked into a data location is skipped silently. Apple engineer Quinn’s “--deep Considered Harmful” is the short version. Use --deep only to verify:

codesign --verify --deep --strict --verbose=2 "MySynth.vst3"

That’s the check worth running before you notarize — it walks the whole bundle and names any nested item that isn’t properly signed. spctl -a -vvv -t install on the finished installer confirms Gatekeeper’s verdict.

Two references worth reading before you start:

• How to code sign and notarize macOS audio plugins in CI — Sudara’s walkthrough, written specifically for audio plugin developers. It covers the certificate types, the exact codesign / notarytool / stapler invocations, and the mistakes that produce silently-missing AUs.
• Apple: Notarizing macOS software before distribution — the official reference.

The whole sequence automates well. If you’re already publishing releases from CI, see Distributing plugins with GitHub Actions for where the signing and notarization steps slot in.

Windows has a parallel-but-milder problem: nothing blocks an unsigned plugin outright, but SmartScreen and antivirus scanners will flag it. See the FAQ on virus warnings.

Distribution

You own full rights to the plugins you create with the licensed version of SynthEdit. You can:

• Distribute plugins for free
• Sell them commercially
• Include them in commercial products

No royalties or additional licensing fees apply.

Automate your releases — rather than exporting and packaging by hand each time, you can have GitHub Actions export the plugin and build Windows + macOS installers automatically whenever you push a version tag. See Distributing plugins with GitHub Actions.

Tips for Professional Plugins

• Test in multiple DAWs (Cubase, Ableton, FL Studio, Reaper)
• Provide sensible default preset values
• Include a user manual or preset library
• Test with different sample rates (44.1kHz, 48kHz, 96kHz)