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();
}
