As mentioned in the last commit. The original reasoning behind these
names was that the HostBridge talks to the host, and the PluginBridge
talks to the plugin, but you could also argue that the HostBridge should
be part of the Wine VST host and the PluginBridge should be part of the
VST plugin. This removes that ambiguity.
I had swapped these names around once before but I think going with
PluginBridge for the plugin and WineBridge for the Wine VST host is the
least ambiguous it can get.
This allows symlinking to a copy of `libyabridge.so.` Now we support:
- A symlink to `libyabridge.so` with a `.dll` file in the same directory
as that symlink.
- A symlink to `libyabridge.so` with a symlinked `.dll`.
- A copy of `libyabridge.so` with a `.dll` file in the same directory as
that copy.
- A symlink to a copy of `libyabridge.so` with a `.dll` file in the same
directory as that copy.
- A symlink to a copy of `libyabridge.so` with a symlinked `.dll` file.
That seems a bit overkill, but hey, more options are always better,
right?
Ardour will send events to the plugin before it has even finished
initializing. This has been fixed back in 2018 but Ardour has not seen a
stable release since then.
https://tracker.ardour.org/view.php?id=7668
This keeps compatibility with some weirdly designed plugins (such as
Kontakt) while avoiding some unnecessary data transformations. Before
this we'd convert from a `DynamicVstEvents` object to a `VstEvents`
object, back to a `DynamicVstEvents` and then finally back into another
`VstEvents` object. With this change we can skip the second half of the
conversions.
This will make sure the sizes match on both the 32 and 64 bit host
applications. This way only the 32-bit application will have to convert
between 32 and 64 bit integers.
This way the 32-bit host can cast them down to 32-bit integers when
needed, and the serialization pipeline can stay fixed. We're not passing
any pointers directly to the other application anyway so this should be
safe!
Also remove any special `effEditIdle` handling.
Apparently plugins rely on the message loop for their internal tasks,
even for things that have nothing to do with GUIs, such as deferring
initialization.
This should not make any difference, but if this event ever gets called
at the same time as the processing then this at least won't cause any
issues with plugins that are not thread safe themselves.
Robbert van der Helm