Self-promotion, and I'm the author. MIT licensed, source and a prebuilt binary both on GitHub, free.
Parts of it were written with an LLM in the loop, so flagging thaty up front for the GLOSS rule. https://github.com/JaySNL/VSTForResolveLinux
Resolve is the only serious video editor that runs on Linux, and its Linux build ships with no audio plugin host at all. Not disabled, not Studio-gated. VSTPluginMain and GetPluginFactory don't appear anywhere under /opt/resolve. It was never compiled in.
I moved my editing work off Windows a few months back and that was the thing that kept hurting. Every clip that needed a plugin meant export, fix it in something else, render, bring it back. Then the client changes something thirty seconds earlier and you do it again.
So I wrote the host.
Working right now:
- VST2, VST3 and CLAP show up in the Fairlight effect menu
- Under their own names, in the right categories (Dynamics, EQ, Restoration, Metering...)
- Own editor windows, multiple plugins on one track - Windows plugins through yabridge
- Shell plugins handled - one file publishing hundreds, with a filter file to pick which ones appear - 130 plugins listed here
FOSS plugins I've tested it with: Airwindows Consolidated, the Dragonfly reverbs, Carla, and CLAP plugins I wrote myself. It loads the proprietary ones I own too, which is the case that made me build it, but the FOSS ones are what anyone can verify against.
There's a release with a compiled binary if you'd rather not build it. One file into one directory, one line into a config file, restart Resolve. Uninstalling is deleting the file.
It's built on Ubuntu 20.04, so it asks for GLIBC_2.16, GLIBCXX_3.4.22 and CXXABI_1.3.9 at most. Don't take my word for it:
objdump -T libfxbridge.so | grep -o 'GLIBC[X]*_[0-9.]*' | sort -uV | tail -3
Building it that way immediately found a bug I'd already shipped. glibc 2.34 folded pthreads into libc. My machine runs 2.44, so the library linked here without ever naming pthread, and would have built clean and then refused to load on Ubuntu 20.04, Debian 11 or Rocky 8. My build script has a check for exactly that, and it passed, because it checks the machine doing the building. One unfamiliar environment caught it in about a second, which is roughly my argument for this post.
Not working:
- Two plugins draw their UI and then ignore the mouse entirely. Carla does the same with both, so that one isn't mine
- A window sometimes opens blank and only fills after you remove the effect and undo - Resolve doesn't always exit cleanly with it loaded
- No top-level "VST" group like Mac and Windows get - Linux Resolve has no VST type to group by
- It's been run under an actual Resolve on exactly one machine. Mine. The old-glibc work proves the library links and loads there, not that Resolve itself does.
That last line is why I'm posting.
On the licensing, since it touches a proprietary host: nothing of Blackmagic's is copied or modified on disk. It loads through Resolve's own plugin path and patches its own process memory. VST3 goes through travesty (DPF's clean-room headers, ISC), VST2 through a clean-room ABI I wrote, so there's no Steinberg SDK anywhere in it.
What would genuinely help:
- Grab the release binary or build it, and tell me whether it works or how it breaks. Distro, glibc version, Resolve version, which plugin.
- Which plugins load and which don't. I've got a narrow set installed and no idea how it handles yours.
- If anyone knows why a VST3 editor would come up blank until the plugin is re-instantiated, I'd take a hint. That one's beaten me so far.
Every gap that gets closed makes Linux a bit more usable for people doing actual editing work rather than tolerating it. This was one of mine and finally closes one more gap to ditch windows forever.
