Hi, When a VST3 plugin has focus in FL Studio 2021, the spacebar (to start/stop) transport is not being passed onto the DAW.
This can be reproduced with the AudioPluginDemo - load the plugin, click on one of the sliders and hit space bar.
This only happens in FL Studio 2021 with VST3 - all other DAWs and VST2 work as expected.
Thx
Any input or thoughts from the JUCE guys on this? thx
Have you tried any non-JUCE VST3 plugins? Do they behave in the same way?
hi, @reuk i guess itâs hard to know what is written in JUCE or not? Got examples of other plugins out there that exhibit the problem, and others that donât - which ones were written in JUCE tho, not sureâŠ
We explicitly tell our controls/views to not take keyboard focus, except for those that need to take focus for editing. If the plugin takes focus, the user needs to click on a window in the DAW itself to get focus back to it before the space bar and other keys work in the DAW. Thatâs undesirable, so we prevent that wherever possible.
ok, interesting - iâll go and add this to see if it makes any difference - thx
Just tried adding the setWantsKeyboardFocus( false ) to the controls and clicking on them still takes focus away from FL Studio.
Make sure the containing component(s) also do not take focus. Still might not work in FL Studio, I donât know. Not a DAW I usually work with. But the workaround should be the same: click on a window belonging to the DAW and it should take focus without any plugin changes.
yep, iâve done that all the way up to the top.
having to click back into the DAW after clicking a button is a workaround on FL studio yes, but itâs not a nice workflow to communicate.
Hi @reuk any more thoughts? The fact that thereâs VST3s out there (e.g. Serum, Phoscyon 2) that donât have this issue suggests itâs not an FL Studio problem, and more likely to be a JUCE issue. Iâve got a client who is waiting to release but doesnât really want to do it whilst having to provide this work around to his customers. Is this something that might get address in the near future? thx
Thereâs a button in the FL editor window border with the tooltip âAllow the plugin to handle keystrokes before the host doesâ. On Windows (you didnât specify a platform so Iâm guessing), disabling that allows the spacebar to work, even when the editor has focus.
At the moment, Windows keyboard handling in plugins works by hooking key events in the main thread. In the case of the AudioPluginDemo, when the editor fails to handle an event (like a space-key press), weâre correctly passing the event to CallNextHookEx, so that the host gets a chance to process it. We can see that the host does receive the event, because it sends it back to the VST3 wrapper via IPlugView::onKeyDown. The VST3 wrapper returns false, indicating that the event wasnât used. Given that, at this point, the host knows that the editor has declined to process the event, I donât see why itâs refusing to use the event itself.
Itâs also worth noting that in this case, we return exactly the same result (kResultFalse) from onKeyDown and onKeyUp as the host checker plugin distributed with the VST3 SDK. However, FL will play when pressing space in the hostchecker, but not when pressing space in the AudioPluginDemo.
As far as I can tell, things âworkâ in the hostchecker example because of the following in the vstgui4 windproc:
if (IsWindow (oldFocusWindow))
{
auto oldProc =
reinterpret_cast<WNDPROC> (GetWindowLongPtr (oldFocusWindow, GWLP_WNDPROC));
if (oldProc && oldProc != WindowProc)
return CallWindowProc (oldProc, oldFocusWindow, message, wParam, lParam);
}
When the editor is clicked, it remembers the window that had focus before this window, and manually forwards key events to that window. Itâs not obvious to me that this is âcorrectâ behaviour. JUCE, on the other hand, sends unhandled key messages to the editor windowâs direct parent. To me, using the parent seems like a more reasonable choice than whichever window previously had focus. If we instead modify forwardMessageToParent so that it sends the unhandled message to GetAncestor (hwnd, GA_ROOT), then pressing space triggers playback. Based on that, my best guess is that the direct parent window provided by FL chooses not to handle the spacebar event by starting playback.
I donât think itâs a good idea to change the recipient of unhandled key events in JUCE. Sending all unhandled key events to the root window, for example, could have unexpected repercussions. Other hosts might be in the opposite situation, and expect events to be forwarded to the parent rather than the root. To me, the current behaviour seems fairly reasonable.
If this is a deal-breaker, perhaps you could contact Image Line and ask them whether my analysis is correct, and if so, why the editor windowâs direct parent doesnât start playback when it receives a spacebar-press message.
Hi @reuk thx for the info - yes, it is Windows (sorry for not specifying) that has the issue - Mac is fine.
My client has an outstanding request with ImageLine (that theyâve not responded to yet), but will get him to provide this additional info and see what they say.
Thx alot!
If this is a new problem in FL Studio 21, please take a look at the wrapper options. On the Troubleshooting page thereâs a new option called âAllow FL Studio to process keyboard presses when the keyboard focus option is onâ. Try enabling that option.
If that doesnât work weâll have to take a look at a plugin that has this problem to see what exactly happens.
Hi - this is not new to FL Studio 21, happens also in 20. However, telling users to turn this option on every time they load a plugin is not really an ideal solution. the option does solve the problem however.
Additionally, keyboard focus is not turned on for the plugin, and behaviour is different for Mac and Windows - Mac works fine and as expected.
thx
Users can save a plugin preset (to the plugin database in FL Studio) to default to specific options, and itâs also saved per plugin type (so you choose it and it should remember that next time you open that plugin).
The option is off by default because too many people complained that their plugins didnât work correctly anymore when the option was first added (and when it was on by default).
Iâm afraid I donât know why this behaves differently on Windows and macOS.
hi, thx for the info!
I can confirm that selecting the âAllow FL Studio to process keyboard presses when the keyboard focus option is onâ does persist for the plugin and this addresses the issue - thanks for your help! 
If you care about this, you might care about a similar issue that happened to me in Reaper (where you would have to click into the editor once).
This fixes it:
void EnshapeAudioProcessorEditor::parentHierarchyChanged()
{
if(isShowing() || isOnDesktop())
grabKeyboardFocus();
}
