I think the idea is that normally the plugin will keep copies of the
pointers to the `VstMidiKeyName` structs passed after initialization,
and the host will just read from them whenever it needs to draw these
labels. Since there's no explicit synchronization or notification going
on there's no way for us to tell that these have changed. It would be
possible to implement this by storing these pointers on the plugin side,
storing the objects on the Wine host side, and then periodically polling
for updates. Right now I chose to just not bother with this because it
will add a lot of complexity for very minimal gain (I only noticed it
was an issue after messing with MDrummer and switching between the pad
and loop modes).
With yabridge 1.2.0 I'll change the regular `yabridge` package to
compile from the source tarball and I'll a new `yabridge-bin` package
that just uses the binaries from the GitHub releases section to confrom
with the usual package naming conventions.
This reverts commit e728dbe5a2.
`std::filesystem` is broken on wineg++, at least with Wine 5.8. Any path
operations will throw a `std::filesystem::__cxx11::filesystem_error`:
what(): filesystem error: Cannot convert character sequence: Invalid or incomplete multibyte or wide character
Instead of just detaching the threads, it's much better to terminate the
Wine process and let the threads terminate themselves.
This fixes#11 on my machine.
Now that I think about it it's pretty obvious why symlinks only work
with hosts that support plugin sandboxing (since your OS will never load
two instaces of an identical .so file into the same process). Still, I
find using symlinks in hosts that do sandbox their plugins to be very
user friendly, especially while developing.
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.
Robbert van der Helm