v0.2.8 - the scan moves out of Resolve and runs eight at a time

The slow first scan moves out of Resolve, gets a progress bar, and runs eight modules at a time.

fxbridge-scan — build the cache before you start Resolve

The scan was always going to be slow once: reading a plugin's name means opening it, and opening a
Windows VST3 through yabridge starts a Wine host. Until now that happened inside Resolve's splash
screen, with nothing to read and nothing to do.

  [##########..............]  42%  139/330  3m11s elapsed  ~4m22s left  MTurboDelayMB

build.sh builds it, installs it and runs it. It ships here beside the library. It is the same
code the bridge runs and writes the same cache to the same place, so Resolve then starts on that
cache and opens nothing.

Two things follow from it being a separate program:

• A plugin that faults while being read takes down a command, not an edit session.
• Ctrl-C is told apart from a plugin faulting. The interrupt deletes the in-flight note, so
  nothing is blamed for a run that was stopped on purpose. Verified both ways: SIGINT keeps the
  19 cached modules and blames nobody, SIGKILL leaves the two that were genuinely open.

Eight at a time

Measured before it was changed, because the fix follows the measurement:

phase	cost
dlopen	0 ms
ModuleEntry	327–352 ms
ModuleExit	26–29 ms
dlclose	0 ms

All of the cost is a separate process starting — so there is nothing to shave off the work itself,
and separate processes start alongside each other. Two modules took 1196–1726 ms serially against
510–951 ms in parallel over three runs each. The whole scan here went from 2,910 s to 1,232 s,
on a set where only two of twenty-one modules are Windows plugins. A collection that is mostly
Windows plugins should do better than that.

FXBRIDGE_SCAN_THREADS sets the number. Default 8, capped at 16.

Bounded, and the bound is the point: the 336 Wine hosts that made this slow in the first place were
unbounded and permanent. Eight, for the length of one open, is a different thing.

A start that ended with modules open runs the next scan one at a time. Eight in flight means
eight stranded names and only one culprit, so a recovery run goes serial and the name that strands
again is the answer rather than a one-in-eight guess.

Also

The plugins' own output — yabridge writes a paragraph for every bundle that holds no Windows
module — now goes to ~/.local/share/BMDAudioPlugins/fxbridge-scan-errors.log instead of through
the progress bar it used to tear in half. It is kept rather than thrown away: if a plugin faults
while it is being read, its last words are in there.

Install

mkdir -p ~/.local/share/BMDAudioPlugins
curl -L -o ~/.local/share/BMDAudioPlugins/libfxbridge.so \
  https://github.com/JaySNL/VSTForResolveLinux/releases/latest/download/libfxbridge.so
curl -L -o ~/.local/share/BMDAudioPlugins/fxbridge-scan \
  https://github.com/JaySNL/VSTForResolveLinux/releases/latest/download/fxbridge-scan
chmod +x ~/.local/share/BMDAudioPlugins/fxbridge-scan

Then, with Resolve closed:

~/.local/share/BMDAudioPlugins/fxbridge-scan

Your existing cache is kept — only plugins it has not read yet are opened.

The binaries

Both built from the v0.2.8 tag in an Ubuntu 20.04 sandbox, so they run on Ubuntu 20.04,
Debian 11 and Rocky 8. libfxbridge.so floors at GLIBC_2.16, fxbridge-scan at GLIBC_2.14.

55056f305a59fc32e86f82478982cd0d92c345bca2d0845066a2f481d459437c  libfxbridge.so
0497b7a8c6e796d7021ba0c4f093f7a9eccc85719b5c3419318f1c0ac9df910d  fxbridge-scan

Known, and not done

Every non-shell module answers exactly one class, and its filename is already the plugin's name —
so a cold scan could open nothing and resolve the class when the plugin is actually loaded,
taking the first run from minutes to seconds. The obstacle is shells: one WaveShell holds 718
plugins behind a filename that names none of them. That needs designing, not typing, and it is not
in this release.