VST3 plugin GUI eats keyboard messages in desktop application

I’m developing a Windows desktop JUCE software which loads VST3 plugins.

When I create a window and add VST3 plugins GUI into it, keyboard listener of my application stops receiving keyboard messages. I have to click with mouse any other part of the screen except the VST3 window to get my software to respond to keyboard presses again.

I have put the following lines into my Window class which shows the VST3 GUI:

    setInterceptsMouseClicks(true, true);
    setWantsKeyboardFocus(false);
    setMouseClickGrabsKeyboardFocus(false);

That doesn’t help with the situation.

As far as I can tell, VST3 plugins made with JUCE don’t present this issue. Only plugins not made with JUCE have this unwanted behavior.

Any suggestions how to fix this, or if there’s an upcoming fix into JUCE?

Do you see the same behaviour in the JUCE examples, e.g. in the AudioPluginHost? If so, this may be a bug in JUCE. Otherwise, I’d recommend checking the AudioPluginHost source to see how it differs from your code.

1 Like

Hard to say for sure. In my software I’m reading all sorts of keys when VST3 plugin windows are open and in focus on screen, so this is easy to test.

But in AudioPluginHost I could only think of pressing Ctrl-S which normally opens up the save dialog window. When any plugin window is in focus (be it made with JUCE or not), that save dialog window does not pop on screen, even though that would IMHO be expected behavior. I don’t know what would be a better test to try in AudioPluginHost, though.

Also when I try to load Reveal Sound Spire VST3 plugin, AudioPluginHost crashes. I first thought this was just happening in my own JUCE software, but AudioPluginHost also seems to have trouble with that plugin.

Bug fixes would be welcome in the near future as this limits the compatibility of VST3 plugins in my software :slight_smile:

It looks like there is a bug in the AudioPluginHost, where key presses don’t reach the application command target when a plugin window has the keyboard focus. The fix looks simple: we can add the application command target as a KeyListener of each PluginWindow. After doing so, the keyboard shortcuts work as expected when a plugin window has focus (ctrl+a opens the audio settings, ctrl+p opens the plugin list window, etc.). We’ll likely publish this change shortly. Perhaps you can use a similar approach in your program.

Note that this pattern of keyboard handling requires the plugin to correctly report whether or not each key press is consumed by the plugin editor. In my testing, FabFilter Pro-Q 4 seemed to do this correctly, while Xfer OTT 1.37 did not.

I can reproduce this behaviour. Unfortunately, the crash seems to happen somewhere inside the plugin itself during the call to setActive(true) on the VST3. On the console, I see that the error code 0xc0000374 is logged during this call, which indicates heap corruption, so I think the plugin itself is buggy. I recommend filing a bug report with Reveal Sound.

Did you try the keyboard fix also with plugins which were not made with JUCE? For example Native Instruments Battery does presented issues, while Valhalla plugins worked fine in my software.

Yes, FabFilter plugins work correctly for me, and those don’t use JUCE as far as I know.

I have two key listeners for the plugin window. For both I use p_plugin_window→addKeyListener(listener_pointer) method to set them up for listening.

But neither of those listeners receive any messages when the VST3 plugin GUI window is in focus. (Native Instrument Battery 4 in this latest case)

This issue has now been fixed on the develop branch:

I tried the latest commit of develop branch and the problem persists at least with plugins not made with JUCE. I tried opening Native Instruments Battery 4 and then pressing Ctrl+S and nothing happened while the Battery window was in focus. Only when I clicked with mouse the AudioPluginHost window, then I was able to get the save dialog window on screen by pressing Ctrl+S.

How to get it working on plugins which don’t report the consumed keys? Ableton Live and other DAWs seem to be able to read keyboard correctly even with those plugins which cause trouble in AudioPluginHost and my software.

As long as the problem persists, simply having many of the common plugin GUIs open on screen + tweaking their knobs results in inability to easily save project file with Ctrl+S, or to start/stop playback by pressing Spacebar, etc. That’s a big issue in my book. I hope there is a fix coming soon. Or even a workaround of some sort.