FabFilter User Forum
FF plug-ins stealing key focus from some hosts?
Hello FabFilter team,
I've got a little problem with your fabulous plug-ins.
When I click anywhere inside their GUI (tested with VST2 versions of Twin 2, Timeless 2 and Volcano 2), they completely take away key focus from my host program, meaning you can't use the space bar to start/stop anymore, until you click outside the plug-in window.
Unfortunately, this is a problem that arises within the host I use all the time: Zynewave Podium (zynewave.com). I've also tried with energy XT 1&2 (where it doesn't work), and Ableton Live 7 - where it works fine! :/
So, since it does seem to work in some hosts, I'm not sure if it's your plug-ins that are at fault here...
I've just now asked the developer of Podium about this, too. Still, if you have any idea where the problem may lie or what to check for, it'd be great if you could write back, or contact Frits (Zynewave) directly!
Thank you.
Hi,
We indeed set the focus to the plugin window if you click in it. This is necessary for the mouse wheel to work on Windows.
The host still has the ability to 'catch' keyboard messages even though it doesn't have the focus, e.g. Cubase does this. (Some hosts even have an option to turn this on or off, because if a plugin implements text entry, this won't work correctly if the host tries to interpret those key strokes as well.)
I don't see how we could support the mouse wheel if we wouldn't take the focus though...
Cheers,
Thanks for the reply, Frederik.
The only other other plug-in I own that has mouse-wheel support for knobs and such is XLN Audio Addictive Drums. When its window has focus, it doesn't take away key focus from 'my' host. Or it passes them through, or something... The mouse wheel also works on AD even if it doesn't have focus. It's not really usable like this, though, since the host program also receives the mouse-wheel action and operates on it (similar to what you said about some hosts' keyboard shortcuts interfering with text entry).
I'll wait for a reply from Zynewave, and see if he can cook something up to catch those key strokes anyway.
Bye!
Hello again,
the reply from Zynewave is in:
"I tried the Volcano2 demo. I also read the comment from fabfilter in the topic you linked to.
Clicking on the plugin Window frame to give the plugin key focus works fine. Podium receives key press messages from Windows (WM_KEYDOWN/WM_KEYUP) and distributes these to the plugin with the editKeyUp() and editKeyDown() VST messages. The plugin can then respond to the key press and return to the host whether it "consumed" the key press. If not consumed, then Podium checks the key for Podium key shortcuts.
It appears that when you activate the Volcano plugin editor by clicking inside the editor window, it consumes the WM_KEYxxx messages, which then is never received by Podium. I read their comment about the mousewheel focus, but I can't see why this should prevent them from letting the WM_KEYxxx messages through to the Podium parent window.
If this works in other hosts, then it could be because these hosts parse keypress messages before Windows distributes the messages to the key focus window."
(The complete thread here: www.zynewave.com/forum/viewtopic.php?t=2093)
Though I'm a non-programmer, the question that springs to mind is if FabFilter plug-ins indeed do not pass along (unused) keypresses to the host program, as other VST's seem to do? As said, my concern is mostly with Zynewave Podium, but it also affects users of energy XT, Mu.Lab (mutools.com), and maybe other lesser-known sequencers. I really hope you'll be able to help!
Bye!
Thanks for the information. We'll look into this for a future update of our plug-ins!
Cheers,
Great - thanks, Frederik. I appreciate it!
Bye!