Heya! I had a similar problem with both surge (which isn’t a juce plugin and where I hand rolled the Linux vst3 event loop) and our juce plugin.
I’ve been working with the bitwig team. The freeze I saw in both vst3s (which matches yours) is fixed in the dev version of bitwig I just ran and should be corrected in the upcoming 3.2 beta 4. They were happy for me to let you know this here in the forum too (I’m just an opensource programmer not a bitwig team member)
If you look in your bitwig log you may see something like warning unregister unknown handler. The innards of the vst3 runloop are painful but bitwig team has fixed the thing that makes that log message.
Interesting, thanks! I was testing this with JUCE-based VST3s and noticed that the event handler wasn’t being called for the X11 fd and it sounds like this should fix it. Do you know when this beta will be available?
Yeah that’s exactly what I saw in surge and then also in our juce plugin. The problem (short version) was that the VST3 api (as you know) as registerHandler( handler *, fd ) and unregisterHandler( handler ), but bitwig was making one handler and then multiplexing internally, so if you did something that registered a new handler transiently (like initialize another xcb or something) it would unregister the same handler as for the main xcb loop. I also had some bugs in surge which had us confused for a bit but once i got those fixed with reaper and your (super duper useful) audiopluginhost we found it.
I got the impression that 3.2 beta 4 will be out ‘shortly’ but I don’t have a date.
I added a fix for the Linux naming issue on the juce 6 branch, so VST3 plugins built with CMake on Linux should work as expected now. Please let me know if you run into any other issues.
The last line is the problem. That file in Contents should be named .so. If I apply the patch in that other issue it gets fixed. But it may be me too. Am I doing something wrong?