BR: Host steals some keyboard commands from the plugin

General JUCE discussion
1

We develop applications that host VST3 plug-ins.
I recently upgraded my JUCE version from 7.0.2 to 7.0.4 and some keyboard commands are no longer received by the plugin, but directly by the host.

This bug does not occur in Windows.
It worked correctly in Studio One5, so it does not appear to be a problem on the plugin side.

The bug was identified in the following combinations:

  • StandardApplicationCommandIDs::del (assigned to delete key)
  • StandardApplicationCommandIDs::cut (assigned to cmd + x key)
  • StandardApplicationCommandIDs::copy (assigned to cmd + c key)
  • StandardApplicationCommandIDs::paste (assigned to cmd + v key)
  • StandardApplicationCommandIDs::selectAll (assigned to cmd + a key)

The bug was NOT identified in the following combinations:

  • StandardApplicationCommandIDs::undo (assigned to cmd + z key)
  • StandardApplicationCommandIDs::redo (assigned to cmd + y key)
  • Other keyboard commands we have defined

JUCE v7.0.3 has improved input handling on macOS, but I am wondering if that fix might be suspect.
Could you please confirm this?

2

It would be helpful if you could provide a simple test-case that worked in 7.0.2 but no longer works on develop. Do you see the issue in the AudioPluginHost, for example?

3

Do you see the issue in the AudioPluginHost, for example?

In the AudioPluginHost, I confirmed that the problem is reproduced in v7.0.4 when cmd + a key is pressed, but not in v7.0.2.
The problem occurs even with v7.0.5.

delete, cmd + c, etc. were not keyboard shortcuts assigned to AudioPluginHost, so they could be operated on the plugin.

4

Thanks for reporting this issue. I’ve pushed a fix here:

I’d appreciate if you could check out this version and test it, to see whether the expected behaviour has been restored for you.

1 Like
5

Thanks for the fix.
Unfortunately, however, the problem was not resolved in my environment.

Allow key equivalents to propagate to inner views if they are not handled by outer views

The commit message is as above, but does this mean that the host (outer view) has priority over the plugin (inner view)?
If so, I don’t think this bug will be resolved.
If the same keyboard shortcut is assigned to the plugin and host, I expect the plugin to pick up the keystroke.

6

Please could you provide some more detail? Are you able to reproduce the issue using JUCE example projects (remember to build everything from develop!). What behaviour are you seeing now?

If I update the AudioPluginDemo’s editor to handle keyPressed events, then pressing focusing the editor and pressing cmd + A while the plugin is hosted in the AudioPluginHost will cause the following to happen:

  • The host window’s performKeyEquivalent is called. The host checks for a focused component that can handle the event, but doesn’t find one, so the event is passed to the the superclass for handling.
  • The superclass forwards the event to the plugin’s view. The plugin has a focused component that can handle the event, so performKeyEquivalent returns true, and event processing ends. The host’s Audio IO window does not open.

I suppose that things might not work if you have components (as opposed to main-menu commands) in the host window that want to handle the same keyboard shortcuts as the plugin. At the moment, I can’t think of a good, general workaround. If we were to always return false from performKeyEquivalent, this would break the case where a component and a main-menu command want to process the same key command. Ideally, the focused component should get a chance to process the shortcut before it is sent to the main menu, and the only place we can do that is in performKeyEquivalent. At the same time, macOS always tries to call performKeyEquivalent from the outermost to the innermost view, so the host will always ‘see’ these events before they reach the plugin.

Assuming that the problem you’re seeing is due to having Components in the host that want keyboard focus: would it be possible to move these shortcuts into the main menu instead?

7

Please could you provide some more detail? Are you able to reproduce the issue using JUCE example projects (remember to build everything from develop!). What behaviour are you seeing now?

I tried AudioPluginHost with the latest in the develop branch and it works fine.
I am sorry that I only checked it with the application we’re developing.

Assuming that the problem you’re seeing is due to having Components in the host that want keyboard focus: would it be possible to move these shortcuts into the main menu instead?

Checking the difference between the implementation of AudioPluginHost and our app, we see that in our app, the component that needs keyboard processing inherits ApplicationCommandManagerListener::applicationCommandInvoked() to pick up the key commands.
Does this mean I should change to picking up all commands with ApplicationCommandTarget::perform() instead of this method?
I will try it and report the result later.

8

I have adapted the implementation of AudioPluginHost as much as possible, including the parts other than the comment mentioned above, and it now works as expected.
I could not pinpoint what was the cause of the problem because there were so many changes, but thank you for your repeated answers.

1 Like