Hi all,
Our JUCE app hosts VST3 plugins using juce::VST3PluginWindow, which works well for the most part.
Like many audio apps, we use the Spacebar as a keyboard shortcut for starting the transport (among many other command shortcuts). Unfortunately, when focused, some plugins appear to swallow keystrokes altogether, so our app never gets chance to intercept them, even at the lowest level (e.g. on Windows, I added breakpoints to juce::HWNDComponentPeer::peerWindowProc() which never get hit).
I even used the Visual Studio Spy++ utility to monitor Windows keyboard messages, which confirmed that some third party plugin UI windows are indeed consuming WM_KEYDOWN/WM_KEYUP messages.
Obviously, I’m seeing this on Windows, but it may also be a problem on Mac. Not easy to tell, since it’s plugin (vendor?) specific.
Thankfully, most plugins behave themselves, handling keystrokes they need and letting unused keystrokes find their way up to parent (JUCE) windows, but there are plenty of popular plugins that exhibit this behavior, including:
- Waves Abbey Road Chambers Stereo
- Eventide 2016 Stereo Room
- Arturia Tape Mello-Fi
- Roland Zenology FX
This makes it impossible for us to handle app-wide keyboard shortcuts/commands while some plugins are focused.
I can’t find a way to fix it that doesn’t involve using low level OS specific workarounds, such as keyboard hooks or subclassing on Windows. Something along those lines may well be necessary, but I would argue it should be handled internally by JUCE itself. Indeed, I did a quick (successful) experiment with the Win32 SetWindowsHookEx() API, but I had to implement most of it in juce_win32_Windowing.cpp out of necessity, and that’s just for Windows.
Am I missing a simpler workaround? Surely it shouldn’t be possible for plugins hosted inside a JUCE app to break JUCE keyboard/command functionality like this, and if not, I’d really appreciate a prompt fix!
Many thanks,
Ben