I have noticed that Reaper on OS X steals spacebar keystrokes when typing into a TextEditor component in my plugin. Pressing spacebar will toggle audio playback in Reaper, even when the TextEditor has focus.
I have observed the same behaviour in a couple of commercial Juce plugins, so I assume that the problem is not unique to me.
We observed similar behaviour. Native Instruments plugins and a few others seem to be able to catch the spacebar tough. Would be nice if that could be fixed at some point.
Not just spacebar, but Return key too is captured by Reaper unless the “send all key presses” option is enabled (wouldn’t be surprised if there were more). Quite annoying.
Command+v (paste) is another key combo that isn’t passed by Reaper. I notice that Diva, which does capture spacebar and return keypresses, doesn’t capture Command+c & command+v either.
I think the only way to get the keyboard input is mentioned in that Cockos forum post:
Our plugins check the “Plugin editor requires keyboard focus” option in the Projucer, but still Reaper won’t give us focus by default.
The same applies to Ardour/Mixbus, there is a specific button to toggle whether or not a plugin is explicitly allowed focus or not. This stops plugins from implicitly capturing things like transport shortcuts, but it can be annoying from the plugin dev side as well
Seems totally to be a host related issue. In the case of REAPER, that’s only with macOS. Everything works fine on Windows. I also checked with the big ones like NI Maschine and its impacted exactly the same way.
I’ve looked at the other threads, this seems to be the most fitting and recent one.
Just ran into this on macOS Reaper. Turns out: Reaper DOES give the Spacebar to the VST3 plugin, but the JUCE VST3 wrapper does not implement IPlugView::onKeyDown, so it’s not getting handled. I tried this in a hacky way. If I send the space to the focussed component and in that case return kResultTrue, the space is processed properly by my text editors, and Reaper doesn’t toggle play.
If you want to try it:
override onKeyDown in juce_VST3_Wrapper, nulltest component and getCurrentlyFocusedComponent, if we got one, call keyPressed on that component. keyMsg 7 is the space bar.
Doing this properly and handling everything is some effort because it needs translation of virtual key codes for many cases. There is a lengthy enum with Steinbergs virtual key codes in the VST SDK.
I do wonder why it’s not implemented in JUCE? This is just plain regular VST3 API and at first glance appears to be a nicer way to cooperate with the plugin host when it comes to keyboard handling, instead of fighting for keyboard input on OS windowing level. I might be wrong of course.
No idea what to do about .AU yet, but there is probably a similar solution.
should be easy enough: Barebones template VST3 plugin, add a text editor. open the PlugIn in latest Reaper on macOS. Try to enter a spacebar in that text editor. Observe that Reaper will toggle play and the space doesn’t arrive in the text editor. You can also use labels, or a custom keyboard listener, the space key will never arrive in the plugin.
if you can’t reproduce this, more investigation might be necessary, but so far it looks like a perfect repro to me. It also affects some “big name” plugins (e.g. Kontakt, try a “search” label).
Apologies, the difficulty wasn’t with reproducing the problem, it was handling the new keypresses presented via onKeyDown.
On a (UK) Macbook typing ( as shift-9 results in the virtual KEY_DOWN event being sent to onKeyDown instead of the ( character. If the target component can handle the down key (like a multiline text editor) then the key is consumed and no ( will appear.
At this point the potential patch moved from something that might be quite an easy addition to one that will require more work to understand, and might involve a breaking change. For the immediate future we’ll be concentrating of the JUCE 7 release, but if anyone wants to dig further in the intervening time then please go ahead.
Hey t0m, thanks for checking and digging out the other forum thread.
I actually felt that a quick solution by adding code to the VST3 wrapper might be too risky too, and it still leaves the problem of VST2 and AU (haven’t checked AAX yet).
Having two somewhat conflicting means of retrieving/handling keystrokes seemed like a dirty solution, who knows what edge cases might arise with all the possible host/wrapper/system combinations…
I don’t think it’s super urgent because I never got any support cases about the issue, but it would be cool to have it tackled properly in JUCE7 at some point. Looking forward to 7!
Hi!
Bumping this thread because this still is an issue as of JUCE 7.0.4. Any news from JUCE? I just talked to a customer who figured to always enter shift-space when entering preset names in one of my plugins… That doesn’t feel right…
I like the behavior how it is today. Almost all the time the plugin should forward space and enter keys to the host, also when focused. We had a lot of problems with that in the past.
The plugin should not take away any keyboard input from the host, but with one exception:
Entering text in text labels when their editors are open and have acquired keyboard focus. If a user sees a blinking caret in a text editor and a focus outline, it’s reasonable to expect that all keyboard input will temporarily arrive only there.
This Reaper setting will result in Reaper no longer responding to keyboard input as long as the plugin has focus, and thus doesn’t work as a solution. Other DAWs behave nicely as long as the plugin behaves reasonably with regards to acquiring keyboard focus.
This is becoming more of a problem when it comes to accessibility, which involves allowing more keyboard control in plugins (given that they have acquired keyboard focus due to some user interaction).
Bottomline: neither stealing all keyboard input from plugins, nor taking all keyboard input away from the DAW is adequate. Both the host and the plugin should comply with established focus model conventions and behave cooperatively.
It feels like it’s in part a Reaper specific issue, but I’d prefer a solid workaround for this in JUCE. If I remember correctly Reaper does indeed use the VST3 interface, so it should be possible to solve this in a non-hacky (if somewhat involved) way, see my earlier post.
If IPlugView::onKeyDown is not handled, Reaper assumes that the keypress was not “consumed”.
