thcilnnahoj.
thcilnnahojEDIT: This behavior has at last been fixed for all FabFilter plug-ins in the Nov 28, 2011 update!
Thank you, FabFilter.
(I couldn’t find a thread dedicated to this, sorry if there actually already is one.)
Lately, I’ve taken some of the plug-ins by FabFilter for a longer, more thorough ride, and I see that they suffer from this, too. As soon as you click anywhere on their GUI’s, none of Podium’s keyboard shortcuts work anymore. The plug-ins in question do not use any keys other than ctrl, shift and alt, as far as I can tell.
@(Quote from another thread) Zynewave wrote:
@kyran wrote:
1. The spacebar should always control the transport, regardless of the current focus
Some plugin editors uses the spacebar key for its own purposes, and thus steals the spacebar keypress so that it never reaches the host. Also, all listboxes in the Podium UI is using the same standard key/mouse shortcuts as used by Windows, so in that case the spacebar is used to toggle elements in a listbox selection. Using the numeric 0 and return key to stop/start is more likely to work no matter where the key focus is.
Because of this, and since it doesn’t work in energy XT 1/2 either, I suspected that the problem lies within their plug-ins. Surprisingly, however, it works fine in Live 7! Does Ableton manage to rob key focus back from the robber…? 😆
It is a little annoying… Do you have an other idea at all on what could be the problem?
I’ll also ask this at the FabFilter forum, maybe they have some light to shed.
If kyran reads this: Which plug-ins do you use that completely steal key focus from Podium?
thcilnnahojFor your information, here’s my thread on the FF forum: http://www.fabfilter.com/topic.php?topic=949
So there seems to be an obvious way how Cubase, Live and maybe others manage to still catch key strokes. Now we need a programmer to figure out how! :-k 😆
ZynewaveI 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 the 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.
thcilnnahojThanks for looking into it! And also for the explanation. 🙂
@Zynewave wrote:
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.
Is this not recommended, then, or something you’d rather not do?
If so, would you suggest I ask FF again about this, and also point them to your post? Theirs are the only plug-ins I know of that exhibit this problem, but judging from some posts I’ve found here, there seem to be a few others, too.
Zynewave@thcilnnahoj wrote:
@Zynewave wrote:
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.
Is this not recommended, then, or something you’d rather not do?
I believe the way I’m doing it is the standard way to respond to key messages in Windows. I prefer to keep to the norm, to ensure compatibility with future Windows versions.
If so, would you suggest I ask FF again about this, and also point them to your post? Theirs are the only plug-ins I know of that exhibit this problem, but judging from some posts I’ve found here, there seem to be a few others, too.
You’re welcome to present my response to the fabfilter developers.
If you are referring to the posts about the space key (start/stop) being inactive when a plugin editor has focus, then that may not be the same problem. That could be the plugin editor responding to Podium that it used a key press, in which case Podium will not use it for its own shortcuts.
thcilnnahoj@Zynewave wrote:
If you are referring to the posts about the space key (start/stop) being inactive when a plugin editor has focus, then that may not be the same problem. That could be the plugin editor responding to Podium that it used a key press, in which case Podium will not use it for its own shortcuts.
Hmm… I’m not sure I understand. 😳
Yes, I am mostly concerned about the basic functionality – starting/stopping playback – with the space bar, and with the numpad, which I use mostly. But the plug-ins by FabFilter don’t use either of these keys. I don’t know which plug-ins the other users I’ve seen posting about this issue (kyran, LiquidProj3ct and Markus, I believe) are using – did you mean that Podium may ignore a space bar key press in cases where the plug-in in focus actually uses it, instead of just silently consuming the key press like in this case? Wouldn’t that be expected?
Come to think of it, the only keyboard shortcut Podium responds to, besides keys for start/stop, is the E key to show/hide plug-in editors. Since this works with all plug-ins I’ve tried so far (except FF, of course), I assume other keys are not consumed either…
I’m curious – does Podium intentionally not act on other shortcuts (S, M, R, for starters) as long as a plug-in window has focus?
Thanks again for looking into it. I’ll post on FabFilter’s forum again later and hope they’ll be able to help. 🙂
Zynewave@thcilnnahoj wrote:
did you mean that Podium may ignore a space bar key press in cases where the plug-in in focus actually uses it, instead of just silently consuming the key press like in this case? Wouldn’t that be expected?
Yes.
does Podium intentionally not act on other shortcuts (S, M, R, for starters) as long as a plug-in window has focus?
Yes, only a limited number of track related keypresses are supported, although I could add the SMRB shortcuts. The thing is that you may have multiple editors open, so if the plugin window has focus it is not obvious which editor should receive key presses that are not used by the plugin.
thcilnnahojOkay, the FabFilter guys said they’ll look into it for a future update.
Ah, how spoiled we are by Podium’s update cycle. 😛
And you’re right – I’ve misunderstood kyran’s feature request, so this issue is only related to FF plug-ins, which I guess I’m the only one using here.