Why don't hosts have a toggle to switch between plugin and host for keyboard and text entry?

[aMUSEd]

I just scrapped all shortcuts in Waveform because it wouldn't let me type anything into the Freestyle plugin search bar without it activating some thing. Did the same in Bitwig 2 recently for the same reason - now have just the bare minimum there as I kept losing work due to some thing getting activated when I was just trying to save patches and type in their names. Many others who prefer shortcuts complain that plugins steal priority away from hosts.

So why don't hosts have a clear toggle switch between plugin and host priority, instead of it being left to the plugin and host to work it out (usually in a messy and illogical way) between them? This should be a standard thing for all plugin hosts to have. Clearly the current state of affairs is not working well.

[waiting man]

Deformation...
I'm so used to find the host on playback over the 800th bar with empty tracks just because I've used space bar to name a preset.

[nitex]

Renoise has a toggle like this at the bottom of the plugin window.

[No_Use]

Reaper also has an option for this, so the question should rather be "Why don't all hosts have..."

[xoxos]

whitespace = for bringing window to focus

whitespace = what modern design despises

[MuTools]

This whole keyboard focus issue could be easily solvable if VST plugins would properly forward unprocessed key messages to the host window. Then no need for hacky keyboard hooks anymore, no need for special switches, ... Then the user can simply continue to use the 'UI focus' = the standard way to choose where he/she wants the key events to go to, seamlessly between host and plugs.

Windows' DefWindowProc lacks forwarding unprocessed key messages to the parent window, that's a conceptual bug and the main reason of these pitas. But this gap is easily solvable if all Windows plugins / UI frameworks would do this:

(pseudo code, and it's especially about the 'else' section)

Code: Select all

case WM_KEYDOWN:
case WM_KEYUP:
  if (ProcessKey(Msg,wParam,lParam)) {
    return(0);
  }
  else {
    host_hwnd=(HWND)AEffEditor->systemWindow;
    return(CallWindowProc((WNDPROC)GetWindowLongPtr(host_hwnd,GWLP_WNDPROC),host_hwnd,Msg,wParam,lParam));
  }

The good thing about this approach is that even seperate plugin windows appart from the main plugin window will forward their unused key messages to the host window, where the host can process them, eg a spacebar key message to start/stop the host.

Unless i'm missing something?

[xoxos]

"unrelated" but just had some fun with this,

implemented vertical drag-adjust controls (eg. knobs) in windows sdk and found, when you leave the window area, releasing the button doesn't set the value.

why, bcs window focus is why.

BUT WINDOWS TO THE RESCUE!!!!

there is a special API for when you release the mouse button outside of the client window!!! it's like the normal API, but has 'NC' in it because it's "non-client".

course, if you try to use it, you'll find, that if you are outside the client window, windows wants to interpret your mouse action as window repositioning, so it drops all the messages.

so basically, WM_NCLBUTTONUP is totally f**king useless, but it exists anyway


thanks for updating your operating systems everyone. sorry about the lack of 90210 bit plugins, but i hope peggy gets her unwed baby back when darryl drives his camaro to the store to buy some more plastic because we need more of that. and definately less sensible, accessible computing.

[Jace-BeOS]

Yup. It's annoying. The finer points of software design continue to be ignored because apparently getting things to work right is not a business priority for anyone.

[exmatproton]

FL Studio has this implemented since the last couple updates. Sooo handy

[kmatheussen]

Ardour and Radium have it too.

[kmatheussen]

This whole keyboard focus issue could be easily solvable if VST plugins would properly forward unprocessed key messages to the host window. Then no need for hacky keyboard hooks anymore, no need for special switches,

That's a third option, I guess. But sometimes you want to let the host get keyboard events no matter what. Perhaps you want to tweak a variable with the mouse in the plugin, while stopping and playing using the keyboard?

[MuTools]

This whole keyboard focus issue could be easily solvable if VST plugins would properly forward unprocessed key messages to the host window. Then no need for hacky keyboard hooks anymore, no need for special switches,

That's a third option, I guess. But sometimes you want to let the host get keyboard events no matter what. Perhaps you want to tweak a variable with the mouse in the plugin, while stopping and playing using the keyboard?

With my proposal that's no prob at all, at the contrary, it's exactly fully supporting such case. When the plug editor receives the spacebar key message because it has the focus, it simply forwards it to the host (via the host window) and so the host will start/stop. So the user can tweak plugin parameters with the mouse and hence give UI focus to the plug editor and meanwhile press spacebar to start/stop the host.

[kmatheussen]

This whole keyboard focus issue could be easily solvable if VST plugins would properly forward unprocessed key messages to the host window. Then no need for hacky keyboard hooks anymore, no need for special switches,

That's a third option, I guess. But sometimes you want to let the host get keyboard events no matter what. Perhaps you want to tweak a variable with the mouse in the plugin, while stopping and playing using the keyboard?

With my proposal that's no prob at all, at the contrary, it's exactly fully supporting such case. When the plug editor receives the spacebar key message because it has the focus, it simply forwards it to the host (via the host window) and so the host will start/stop. So the user can tweak plugin parameters with the mouse and hence give UI focus to the plug editor and meanwhile press spacebar to start/stop the host.

Sure, but what if the plugin uses the space bar for something?

[bustedfist]

I don't think we've reached a point where a computer can read user intent. This being a window focus issue, until it is so, it's up to us to pay attention as to what has focus. Anything else is a slip-shod workaround, like putting a bandaid on a sucking chest wound. I know it's hard to admit one's failure to accept responsibilities, not just on this subject but across life's board, but let's call a spade a spade.

[MuTools]

Sure, but what if the plugin uses the space bar for something?

Of course there can always be the case where a plugin and the host use the same key for some action. I agree with bustedfist, in such case the user has to indicate what he wants via the UI focus. But then that's also the good thing about this system that the user has the final control. And even via an easy and standard way: The UI focus. That's not the case with keyboard hooks or special switches which are here or there or nowhere.