v0.2.0 - editors that open, and settings that survive a reload

Three people ran v0.1.3 on three machines. Two of them found a bug that could not be seen on mine.

The first editor could never open by itself

BridgeEditorReassert is the only thing that opens a plugin window without you pressing Resolve's
panel button, and it runs on the X event pump. The pump was started inside PluginWindowCreate -
so the thread that opens the first window could only start once a window already existed. Nothing
could break that circle.

It was invisible here because Resolve's panel button opens the editor directly, so every window on
this machine was opened by hand. Reported by u/Stroomer0 on Fedora 44: three plugins listed, no
window, ever.

The pump now starts when a plugin is claimed, not when a window is made.

An editor that would not reopen

Two separate causes, both from Delirio's log.

Closing one plugin's window used to mark every open editor closed. That was harmless until
v0.1.1 added the re-assert loop, and then it meant one close made the bridge forget every other
window. The pump now names the effect that owns the window that closed.

And closing the window with the window manager tells the bridge and cannot tell Resolve, so
Resolve's editor object went on believing it was open - your next press of the panel button was
spent hiding a window that was already gone. A hide that arrives while the window is already
closed is now read as a show.

Settings survive a project reload - opt in

FXBRIDGE_STATE_STORE=1 /opt/resolve/bin/resolve

The bridge now asks each plugin for its own state and hands it back the next time that plugin
loads. VST2 through effGetChunk, with a parameter sweep for plugins that keep no chunk; VST3
through IComponent::get_state; CLAP through clap.state. Saved on a timer and on every project
load, so switching projects keeps what you just changed.

Verified end to end on five plugins across all three formats, VST2 and VST3 both through yabridge.

It is opt-in because it is keyed by the plugin, not by the effect. Two instances of one plugin
in a project share one file, and both come back with whichever was saved last. Read the readme
section before turning it on.

AudioPluginPreset was the obvious place for per-instance state and it is a dead end: both of its
vtable slots were traced through a session with project saves and a reload, and Resolve called
neither, while eight other traced slots on the same object fired normally. That object serves the
preset menu, not the project.

Also

Every thread this library starts is now named - fxb-xpump, fxb-tick, fxb-carla - so
top -H -p $(pgrep -f /opt/resolve/bin/resolve) can answer a CPU question instead of showing 300
threads called GUI. On a report of 20-25% idle CPU, not reproduced: measured here at 0.10% of one
core with five plugins loaded, and no threads at all with none.

The binary

libfxbridge.so, built in an Ubuntu 20.04 sandbox so it loads on older distributions. Floor is
GLIBC_2.16, CXXABI_1.3.9, GLIBCXX_3.4.22; zero undefined symbols when checked inside that
same old rootfs. What that does not prove is that Resolve runs on a distribution that old -
the bridge was tested there, the host application was not.

sha256  84dfc053d0708ecbdfe442bf9bd308a4d41f6b0f29fb7eecef1eeada1ad61714

Install it with Method 2 in the readme. One config line, and the library goes in
~/.local/share/BMDAudioPlugins/.

Still true

Not a supported product. It patches structures inside Resolve's process at run time and can take
Resolve down mid-edit. Save often.