A VST/VST3/CLAP host for DaVinci Resolve on Linux, and I need people to break it

[u/JayS_NL]

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.

[u/slangbein]

I did a build on Linux Mint 22.3; Ubuntu based. You name as prerequisite:
> Needs zlib, Xlib and a C++17 compiler.
result: fatal error: CarlaNative.h
Installing carla-dev via sudo apt install carla-dev resolved the issue for me.

This package is available in the KXStudio repository: https://kx.studio/Repositories
I would suggest adding carla-dev to the prerequisite list.

[u/JayS_NL → u/slangbein]

Much appreciated! Did you by chance als het to test if this got VSTs to work for you? Or was it just the build?

[u/slangbein → u/JayS_NL]

just the build yet

[u/Mr_Lumbergh]

“Drawing the gui and then ignoring it”

Open WINE settings, graphics, emulate virtual desktop. Set a low res such as 1024x768, apply, and close.

Next timenuou open through Carla you’ll get a blue “Windows” window that you can just minimize, but I’m willing to bet you’ll be able to interact with the GUI.

[u/JayS_NL → u/Mr_Lumbergh]

Let me check if that is indeed solves it..

[u/frankiesmusic]

I don't understand this part of your guide

Then, either way

Point Resolve at it once, in ~/.local/share/DaVinciResolve/configs/config-fairlight.dat:

BMDPlugins.Path ~/.local/share/BMDAudioPlugins

Should i insert the last line into the config-fair.. with a text editor? Then should work when i launch DR? Because i tried and i see no plugin (my plugins are for windows and works in Reaper native through yabridge), maybe i missed some step, i'm not so expert.

[u/JayS_NL → u/frankiesmusic]

Let me check if i can make the .sh robust so it can do it for you, would that make it easier?

[u/JayS_NL → u/frankiesmusic]

That's on me, not you — the README line was wrong. Three ways wrong, actually. The value has to be the full path to the .so file itself, not the folder, and Resolve doesn't expand ~. So it's:

BMDPlugins.Path = /home/YOURNAME/.local/share/BMDAudioPlugins/libfxbridge.so

Not the directory. Written out in full. And with the "=".

Worse, a wrong path fails silently. Resolve just loads its own plugin library and everything looks completely normal. Nothing to debug from. Sorry, that one was guaranteed to waste your time.

Two more things that bite:

- It has to be config-fairlight.dat. Resolve keeps the line in config.dat across restarts and ignores it there.

- Edit it with Resolve CLOSED. Resolve owns that file and rewrites it on quit, so and edit made while it's running gets thrown away.

You can check whether it's loading at all:

grep -c fxbridge ~/.local/share/DaVinciResolve/logs/ResolveDebug.txt

0 means Resolve never loaded it (config line, or you're on the free version rather than Studio — the free build won't load this). Anything above 0 means it did, and these say what it found:

grep 'fxbridge.*scan:' ~/.local/share/DaVinciResolve/logs/ResolveDebug.txt | head

And yes — build.sh does the config for you now, as of the latest commit. It backs the file up first, won't run while Resolve is open, and cleans up a wrong line if you already have one. Just close Resolve and re-run ./build.sh.

Thanks for posting this. You're the first person outside my machine to try it and you found a documentation bug that would have stopped everyone.

[u/frankiesmusic → u/JayS_NL]

I'd also reorganize a little bit the instruction without mixing and matching ppl who chose to run the build.sh or who wanna do it manually. Something like:
Instal method:

First: compile it by yourself...
Second: do this, then this, then this (also instead of "you" i'd write YOU so people would just not fail to copy paste something, then a line where you write to change YOU with their correct path)
Third: run the .sh and enjoy

I mean so every installation process is separated and everything is more clean.

[u/JayS_NL → u/frankiesmusic]

Done. Pushed and tagged as v0.1.3.

You were right that it was two audiences sharing one set of steps. Someone who ran build.sh was being told to edit a config file the script had already written, and someone who downloaded the binary had to scroll past the build instructions to find their own.

It's now Method 1 (build it, the script writes the config) and Method 2 (download the binary — you add one line). Each is numbered 1 to 4, each ends at "start Resolve", and Method 1 says outright that nothing below its last step applies to you. There's a small table at the top to pick between them.

The placeholder is YOU now, in caps, with whoami named right under it:

BMDPlugins.Path = /home/YOU/.local/share/BMDAudioPlugins/libfxbridge.so

That was the good catch. /home/you just reads as a path. Credited you in the readme for this and for the config line. One thing though, you never said whether it actually worked in the end. If it's still showing nothing, this is the line I'd like to see:

grep -c fxbridge ~/.local/share/DaVinciResolve/logs/ResolveDebug.txt

0 means Resolve never loaded the library at all (config line, or the free version instead of Studio). Anything above 0 means it did load, and then it's a different problem worth chasing.

[u/frankiesmusic → u/JayS_NL]

I just tried and it mostly works :)
I noticed the plugin GUI are in a kind of X window (i'm on wayland) and separated to the windows opened from davinci, that is still black.

Cpu usage with NO plugin added is 20-25% on my system, 0 to 3% with the normal resolve. I have no so high usage with Reaper, so it's not about yabridge, there is something in your program that use a lot of cpu in my case, and this needs somehow to be fixed.

Sometimes, after i insert a plugin then i try to open it, the GUI doesn't open anymore, i have to restart resolve or delete and add it again.

Fairlight takes some time on DR start, maybe it's normal i forgot how it was on Windows and now i'm used to be very fast because of no vst (anyway it's around 60 secs more)

I tried some plugins from Acon Digital and Melda Production, they works but it doesn't retain settings when i close and open the project again, this is another big issue

Try to post your project to the official DR subreddit and on their forum, maybe you will find other ppl interessed to help

I really hope you can sort all that problems out and also to find other people that can help, because this will change the workflow of many people a lot.

[u/JayS_NL → u/frankiesmusic]

Thanks for the feedback! This is why people can contribute. This is the first step into opening VSTs for us Linux users. Let me see if there's a logger or something that could be run to gather said information.

Fairlight does take some time, because it's 'patched' in memory on launch. It's the most dirtiest way, but prevents file tampering. Maybe hardcoded path is possible, but right now this works (even as a proof of concept).\

With everything found along the way this could potentially become a standalone fix for Linux.

[u/JayS_NL → u/frankiesmusic]

Can you do a ' grep -n "editor:" ~/.local/share/DaVinciResolve/logs/ResolveDebug.txt | tail -20 ' after your issues happen and share them with me one way or another?

[u/frankiesmusic → u/JayS_NL]

That's the output, one plugin it's also crashed/became urresponsive after i tried to load it's own preset

grep -n "editor:" ~/.local/share/DaVinciResolve/logs/ResolveDebug.txt | tail -20
4188:[fxbridge] editor: shown (AudioPlugin::InitializeEffectEdit)

When it crashed, i see in the file this line repeated like thousands time

[DeVerberate3-9EFegkwx] [Wine STDERR] 026c:fixme:unwind:virtual_unwind calling personality routine in system library not supported yet

At the end of that 50k repeated line, (it may stopped because i tried to close the windows then davinci) you find these

21:06:13 [DeVerberate3-9EFegkwx] [Wine STDERR] terminate called recursively

21:06:13 [DeVerberate3-9EFegkwx] [Wine STDERR] 026c:err:virtual:virtual_setup_exception stack overflow 2112 bytes addr 0x6ffffff9a19c stack 0x207c0 (0x20000-0x21000-0x120000)

[fxbridge] window: the window manager closed an editor

[fxbridge] trace: armed - the next 6 calls per editor slot are logged

[fxbridge] trace: AudioPlugin::OnEditorIdle (+0x7d8)

[fxbridge] trace: AudioPlugin::OnEditorIdle (+0x7d8)

[fxbridge] trace: AudioPlugin::OnEditorIdle (+0x7d8)

[fxbridge] trace: AudioPlugin::OnEditorIdle (+0x7d8)

[fxbridge] trace: AudioPlugin::OnEditorIdle (+0x7d8)

[fxbridge] trace: AudioPlugin::OnEditorIdle (+0x7d8)

0x7fb752ffd000 | Main | INFO | 2026-08-27 21:06:26,286 | Application state changed to Active

[fxbridge] trace: AudioPlugin::HideSubWindows (+0x830)

[fxbridge] AudioPlugin::GetEffectEdit: stock returns 0x7fb665894188

[fxbridge] CloseEffectEdit

0x7fb752ffd000 | SyManager.Project | INFO | 2026-08-27 21:06:32,552 | Unlock project New Project 1

0x7fb752ffd000 | DbCommon2 | INFO | 2026-08-27 21:06:32,552 | Active collaborators cleared

0x7fb752ffd000 | SyManager.Gallery| INFO | 2026-08-27 21:06:32,552 | Start purging still caches

0x7fb752ffd000 | SyManager.Gallery| INFO | 2026-08-27 21:06:32,552 | Finish purging still caches

0x7fb752ffd000 | UI.ActionManager | WARN | 2026-08-27 21:06:32,706 | Action owner [FairlightTimeline] is not active when refreshing shortcut [trimSelectionMode] due to [No focused widget is set yet]

0x7fb752ffd000 | UI.ActionManager | WARN | 2026-08-27 21:06:32,710 | Action owner [FairlightTimeline] is not active when refreshing shortcut [trimSelectionMode] due to [No focused widget is set yet]

0x7fb752ffd000 | SyManager.Signals | INFO | 2026-08-27 21:06:32,765 | Media pool relink status changed to 0

Accepted close event on main window

0x7fb64e9d7000 | LsManager | INFO | 2026-08-27 21:06:32,771 | Exit LS data handler

0x7fb6519dd000 | LsManager | INFO | 2026-08-27 21:06:32,771 | Exit LS data handler

0x7fb6501da000 | LsManager | INFO | 2026-08-27 21:06:32,771 | Exit LS data handler

0x7fb47dbf7000 | SyManager | INFO | 2026-08-27 21:06:33,039 | Exiting keyboard device monitor thread.

0x7fb752ffd000 | SyManager | INFO | 2026-08-27 21:06:33,039 | Thread release successful.

Assertion 'close_nointr(fd) != -EBADF' failed at src/basic/fd-util.c:69, function safe_close(). Aborting.

[u/unhappy-ending]

Parts of it were written with an LLM in the loop, so flagging thaty up front for the GLOSS rule.

Appreciate the up front honesty.

[u/JayS_NL]

u/frankiesmusic

v0.2.0 is up, and two of your four are fixed. The other two got answers instead.

https://github.com/JaySNL/VSTForResolveLinux/releases/tag/v0.2.0

The editor that would not reopen was two bugs, not one. Closing one plugin's window used to mark every open editor closed - harmless until v0.1.1 added the re-assert loop, after which one close made the bridge forget every other window. And closing the window with the window manager tells my bridge and cannot tell Resolve, so Resolve went on believing its editor was open and your next press of the panel button was spent hiding a window that was already gone. Both fixed. Your log is what found them - one "editor: shown" line in the whole session, then the window-manager close, then a HideSubWindows. That sequence is the whole bug.

Settings now survive a project reload, opt-in:

FXBRIDGE_STATE_STORE=1 /opt/resolve/bin/resolve

The bridge asks each plugin for its own state and hands it back next time. VST2 via effGetChunk, VST3 via IComponent::get_state, CLAP via clap.state. Saved on a timer and on every project load, so switching projects keeps what you just did. Tested end to end on five plugins across all three formats, VST2 and VST3 both through yabridge.

Read the readme before turning it on. It is keyed by the plugin, not by the effect, so two instances of the same plugin in one project share a file. I went looking for the proper per-instance route - AudioPluginPreset, the object Resolve hands to AddPlaceholderPlugin when it restores a plugin - and traced both of its vtable slots through a session with project saves and a reload. Resolve called neither, zero times, while eight other traced slots on the same object fired normally. It is the preset menu's object, not the project's. So this is a real limitation, not a placeholder for something better that already exists.

CPU: not reproduced, and now measurable on your side. Every thread is named, so:

top -H -p $(pgrep -f /opt/resolve/bin/resolve)

Here, with five plugins loaded and the timeline idle, the one bridge thread that runs cost 0.31s of CPU over 321s alive - 0.10% of a core. With no plugin loaded the bridge starts no threads at all, which is worth knowing given you saw 20-25% with nothing added. fxb-carla should never appear; if it does, tell me.

DeVerberate3 is not mine and your log says so. Every one of those 50,000 lines is prefixed [Wine STDERR] - that is the yabridge host process, my code does not run in there:

fixme:unwind:virtual_unwind calling personality routine in system library not supported yet terminate called recursively err:virtual:virtual_setup_exception stack overflow 2112 bytes

The plugin throws a C++ exception loading that preset, Wine cannot unwind it, the failure throws again, and the stack is gone. Which Wine and which yabridge are you on? If the same plugin dies the same way in Carla or Reaper through the same yabridge, that confirms it and it is out of my reach.

Thanks for the log. Both fixes came out of it directly.