VXN 0.3.1

The macOS plugins are code-signed. Every macOS download in 0.3.0 — both formats, both products — was unsigned, and a host that validates a plugin before loading it refuses to load it at all. If VXN1b or VXN2 never appeared in your plug-in list on macOS after installing 0.3.0, this is why, and 0.3.1 fixes it.

Nothing else changed. No DSP, no parameters, no presets, no faceplate. Windows was never affected. If your macOS plugins already work, you do not need this release.

---

What was wrong

A macOS plugin bundle has to carry a code signature that covers its contents. Ours never got one: the bundler assembled the .clap and .vst3 and shipped them straight out, and nothing in the release pipeline signed or checked them.

On Apple Silicon that goes unnoticed for a while, because the linker ad-hoc signs the arm64 slice by itself. The x86_64 slice of a universal build gets no such treatment, and neither does the bundle as a whole, so:

$ codesign --verify VXN2.vst3
VXN2.vst3: code object is not signed at all

Hosts differ in how much they care. The plugin still loads if the host simply opens it — the binaries are intact, and nothing about the audio was ever wrong. But a host that validates first rejects it outright, and reports it the same way it reports a file that is not a plugin at all. Ableton Live logs:

Failed to load plugin: code has no resources but signature indicates they must be present
VST3: not a plugin

Which is why this reads as "Live cannot see my plugin" rather than as a signing problem, and sends you rescanning folders that were fine all along.

If you installed 0.3.0

Replace the bundles with the 0.3.1 downloads. Nothing else to do — same settings, same presets.

If you would rather not re-download, signing them in place works and is what 0.3.1 does at build time:

codesign --force --sign - ~/Library/Audio/Plug-Ins/VST3/VXN2.vst3
codesign --force --sign - ~/Library/Audio/Plug-Ins/CLAP/VXN2.clap
codesign --force --sign - ~/Library/Audio/Plug-Ins/VST3/VXN1b.vst3
codesign --force --sign - ~/Library/Audio/Plug-Ins/CLAP/vxn1b.clap

Then rescan in your host (in Live: Preferences → Plug-Ins → Rescan).

Quarantine, still

Separately from the above, macOS quarantines anything downloaded through a browser, and these plugins are not notarised. If a plugin still does not appear after a rescan:

xattr -dr com.apple.quarantine ~/Library/Audio/Plug-Ins/CLAP/vxn1b.clap
xattr -dr com.apple.quarantine ~/Library/Audio/Plug-Ins/VST3/VXN1b.vst3
xattr -dr com.apple.quarantine ~/Library/Audio/Plug-Ins/CLAP/VXN2.clap
xattr -dr com.apple.quarantine ~/Library/Audio/Plug-Ins/VST3/VXN2.vst3

Signing and notarising under a Developer ID would remove this step too. That is a separate piece of work.

So it does not happen again

The release job now verifies every macOS bundle before attaching it: that the signature validates, that the resource seal exists, and that both architecture slices are signed. It sits next to the existing check that the VST3 actually embedded the engine — a guard that exists because that failure shipped too.

This one shipped four times because nothing looked at it.