v0.2.3 - settings that live in the Resolve project

Your plugin settings are in the project now. Nothing to turn on.

A hosted plugin's own state travels inside the effect's AudioPluginPreset, so it belongs to that effect, it moves with the project, and it survives a chain that gets rearranged. The file store that did this job before is now a fallback, and still opt-in.

How it got here, and two things this project got wrong

The v0.2.1 notes said a project save asks the effect nothing, on the evidence that StorePreset and LoadPreset fired zero times across a session. That was measured on the wrong vtable slots — the primary pair. Resolve holds an AudioPlugin* and calls the thunks. Watching the right pair, LoadPreset fires once per effect on every project load and StorePreset fires on every save.

An engineering-log note also said the Linux build contains no VST host class. It contains 198 symbols of one. Reading it is what made this release possible, and both notes are retracted where they stand.

Riding in Resolve's own channel

Resolve's VST host does exactly this. VSTPlugin::StorePreset picks between two payload shapes on one AEffect flag — a parameter table when the plugin has no chunk, the plugin's opaque chunk when it has one — and both travel in the same pointer and length, with a type tag saying which. The serialised header carries that length and tag through the project file, with a uint32 ceiling.

The bridge leaves the tag alone and appends its chunk behind the carrier's own payload, behind a footer. On the way back in the length is set to the carrier's own for the stock call and restored afterwards, so Resolve's parser never sees a byte it did not write.

Also fixed

A crash on project load. GetControlType is the one accessor of twenty-nine in BMDAudioPluginImpl that indexes the control vector with no bounds check, and Fairlight calls it for every index while deserialising.

A fault handler. A crash now writes a named backtrace to ResolveDebug.txt, because systemd-coredump drops a process this size.

Measured

Eight effects on one timeline, file store switched off so nothing else could have supplied them: eight attached on save, eight restored on load, smartEQ4's 2,320,783-byte chunk included. Zero faults on either half.

Known: a plugin-only edit does not mark the project modified

Resolve serialises the effects model only when it already thinks the project changed, and a change made inside a plugin's own window is invisible to it. Nothing is lost — it is written on the next thing you do that Resolve can see. Measured: a plugin-only edit then Ctrl+S produced zero saves; a fader on a track carrying no effects at all produced eight, one for every effect in the project.

FXBRIDGE_STATE_STORE=1 covers a session that changes nothing else at all.

Install

See the readme. Every release and what changed in it is in CHANGELOG.md.

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

The binary

Built in an Ubuntu 20.04 rootfs, not on a current distribution. Floor GLIBC_2.16, CXXABI_1.3.9, GLIBCXX_3.4.22, and zero undefined symbols when checked inside that same old rootfs — which covers Ubuntu 18.04, Debian 9, Rocky 8 and Fedora 25 upward.

sha256  7b0c504364e635f166ed1fe0a475d93de93dfc2a262d68177d43ff6a4a4a9107

That does not prove Resolve runs on a distribution that old. The bridge was tested there, the host application was not.

The build is scripted now: tools/release-sandbox.sh makes the rootfs, tools/release-build.sh v0.2.3 compiles the tag inside it and refuses to emit a binary with undefined symbols.