This should in theory prevent Nimble Kick from triggering a stack
overflow when the event loop timer procs before `IPlugView::attached()`
gets called and the plugin hasn't been registered yet. I haven't seen
any other VST3 plugins trigger a race condition here.
I've seen this happen once or twice. Earlier on (in #40) we could get
away with just reparenting the window another time. But here both
reparents succeed, and the issue still happens. But a reparent notify
for `parent_window` did appear on system affected by this issue, which
is very odd. Hopefully this will help.
We should of course not expect all global memory to be a HDROP, oops.
Apparently REAKTOR sometimes uses the drag-and-drop system for its own
internal data.
When the user has some sort of hardening going on, we might not be able
to read the Wine process's memory. In that case this check would return
`false` even though the process is still running. To combat this, we
should explicitly check for `EINVAL` which is returned when the file
doesn't exist at all or when it's a broken 'symlink' (even though it
isn't really a symlink).
This is the same way (minus the mapping check part) that `xprop` and
`xwininfo` filter windows when clicking on them. REAPER's toplevel
window apparently doesn't process any keyboard input when the mouse
cursor is located outside of that window.
This should fix#118 without breaking our _other_ workaround from
yabridge 3.4.0 to fix the issue where a plugin would freeze if it would
try to resize itself while at the same time it sent parameter changes
from the audio thread. (and both of these issues of course are caused by
the same JUCE bug)
This is super difficult to trigger on purpose, but I did run into it at
least once just now so it seems like a good idea to at least make sure
that this doesn't happen.
REAPER initializes the plugin's editor first before reparenting the
parent window to the FX window, so our `topmost_window` didn't actually
refer to the FX window.
JUCE incorrectly calls `IComponentHandler::performEdit()` from the audio
thread instead of using the output parameter changes queue, so this
would also cause GUI resizes to be handled from the audio thread if they
come in at the same time as such a parameter change.
This is needed as a workaround to support Waves VST3 plugins.
Right now does does not actually fix the issue because the arguments are
not updated in the subclasses. The next commit will fix this.
If pruning results in a directory becoming empty, then we should remove
that directory. This approach won't touch any directories that we aren't
pruning from.
This commit does a couple of things since the refactoring made it
difficult to split these things up:
- The counts for managed and new plugins are now always correct, even
when plugin directory A contains a symlink to plugin directory B.
- Orphan files will now be pruned from managed VST3 directories, making
switching between different architectures easier. (the previous
approach involved nuking the entire bundle, which of course has a
bunch of downsides)
Some interaction between JUCE and Wine would cause these cursors to be
hidden and then never shown again. This is of course more of a temporary
workaround until the issue gets solved within Wine.
We would completely remove VST3 bundles that yabridgectl does not know
about anymore, but we would not remove leftover files within bundles.
This could otherwise cause issues when messing with 32-bit and 64-bit
versions of plugins or yabridge itself.
Since we're using the XDG base dir package in yabridgectl we were
already doing this there, so it makes sense to also do this in yabridge
itself even though it's very unlikely the user will have this set.
This makes the initialization message reflect the correct Wine version
when using a `WINELOADER` script to change between Wine versions
depending on the Wine prefix.
And print a more descriptive error message instead. This is only
relevant when using a `WINELOADER` that causes `$WINELOADER --version`
to not output anything.
Robbert van der Helm