My biggest showstopper with Waveform 9...

[dRowAudio]

This shouldn´t be neither very difficult nor very time intense...

I've never heard that before...

I am not a programmer (obviously)... so this was a good guess... but sorry:

Is it hard work to i.e. tell your plugin wrapper to block/reserve it for the host the spacebar and translate shift+spacebar for the plugin as spacebar instead???

Yeah, because we don't actually get calls for every key that's pressed.
When you load a plugin, it has its own kind on window and if it's the foreground it will get all key presses.

What's supposed to happen is that if the plugin window doesn't need that key press (e.g. because it doesn't have a label active or similar), it just passes the key press on up the hierarchy to our window and we can deal with it, knowing that it should be used to start/stop the transport.

If the plugin window consumes that key press, even if it doesn't use it, we have no way of knowing that a key was ever pressed.

What I imagine other hosts do, it constantly re-grab keyboard focus from the plugin. This could be an equal pain as it means you wouldn't be able to type in a value to a text box or use arrow keys to nudge the last control that was touched etc.

The plugin should be an extension of the host, and as such work in the same way that other windows do, not stealing key presses that they have no interest in.

(As a slight aside, there might be a way to add OS-level hooks to try and intercept all key presses to a window but this would be incredibly hacky, not to mention time consuming. Remember everything we do that's platform specific has to be done and tested across Windows, Mac and half a dozen Linux variants. With this solution, you'd get equally dodgy behaviour if you, for example were trying to type a name in a plugin text box with spaces in, it would continually start and stop the host playback).

For well behaved plugins (which in my experience is at least most of the big-name companies) this isn't an issue. They deal with key presses correctly. There's no way I'm going to be able to get clearance to research, implement, debug, test, deploy and test this again. This could easily be 3 weeks of dev time...

[Trancit]

...
What I imagine other hosts do, it constantly re-grab keyboard focus from the plugin. This could be an equal pain as it means you wouldn't be able to type in a value to a text box or use arrow keys to nudge the last control that was touched etc.

No matter how they did it, but they did it... and I never encountered not even the smallest problem with any of these impementations...

For well behaved plugins (which in my experience is at least most of the big-name companies) this isn't an issue. They deal with key presses correctly. There's no way I'm going to be able to get clearance to research, implement, debug, test, deploy and test this again. This could easily be 3 weeks of dev time...

Of course, I understand, that it would be easier if all plugins behave like that...

Nevertheless, what I don´t understand:
The DAW host the plugin... my keyboard stroke goes from my keyboard through the rest of the hardware to the OS, which passes it to the open programm, which is the DAW and then to the plugin...

...from my understanding, the DAW receives the keystroke first... and you have no way to deal with this key stroke before the plugin gets access to it???

[Trancit]

For well behaved plugins (which in my experience is at least most of the big-name companies) this isn't an issue. They deal with key presses correctly...

Most of the big name companies??? TBH...most of my "big names" aka "most used" sadly doesn´t work:

Fabfilter... doesn´t work
Melda Production... doesn´t work
Sonic Academy... doesn´t work
Sugar Bytes... doesn´t work
Native Instruments... doesn´t work
HoRNet...doesn´t work
Image Line...doesn´t work
SampleMagic...doesn´t work
Free plugins like Oril River, Loudmax ...doesn´t work
Xfer Records...doesn´t work
UVI...doesn´t work
Slate...doesn´t work
Synth1...doesn´t work
KV331 Synthmaster...doesn´t work
ToneBoosters... doesn´t work
TDR VOS...doesn´t work
Valhalla... doesn´t work
Klanghelm...doesn´t work
Reveal Spire...doesn´t work


Voxengo ...works
Waves... works
Camel Audio...works
KiloHearts... works (of course... they call it: The Works!!! hihi... )
Cableguys...works
MuLab ...works
Spectrasonics...works
Lennar Digital...works
Air Tech...works
Tone2 ...works
Vengeance...works

There are in my case double as many developers, which don´t work in Waveform vs. working...

[gavindi]

Off point, I know but thank goodness my midi controller (Axiom Air-32) has dedicated play/stop/record buttons.

Mine sadly not...

Feels bad, man.

[Trancit]

Off point, I know but thank goodness my midi controller (Axiom Air-32) has dedicated play/stop/record buttons.

Mine sadly not...

Feels bad, man.

It does...

[fromwithin]

Nevertheless, what I don´t understand:
The DAW host the plugin... my keyboard stroke goes from my keyboard through the rest of the hardware to the OS, which passes it to the open programm, which is the DAW and then to the plugin...

...from my understanding, the DAW receives the keystroke first... and you have no way to deal with this key stroke before the plugin gets access to it???

You've already said that you're not a programmer, and that's why you don't understand. Just because you think it should be simple doesn't make it so. The illusion of knowledge is a dangerous thing.

Every window has its own processing loop that receives events from the operating system. If any program opens a child window, the child window receives its own independent events that the main program does not see unless the child window returns them to the operating system and says "not interested in this". When the child window is in focus, it becomes more important than everything else, so the operating system then exclusively sends it the mouse and keyboard events. Unless they are returned as "not interested", the main program will never see them.

So no, the operating system does not pass the keyboard events to the DAW, which passes them to the plugin's window. The operating system passes them directly to whichever window is in focus. The DAW has no way of knowing that a key has been pressed if the plugin is in focus unless the plugin explicitly chooses to return them.

[MBO]

The DAW has no way of knowing that a key has been pressed if the plugin is in focus unless the plugin explicitly chooses to return them.

Good explanation but this sentence is not true. There are low-level methods to capture keyboard/mouse events. As stated above this can lead to another class of errors and problems but technically is possible and often used.

[Trancit]

Everybody else was able to manage this problem (without any noticeable problems for the user) so I stay with that point...
It cannot be too difficult to realize compared to the problem of the userbase that most available plugins doesn´t behave as they should and never will...

It´s all about priority... and for me personally it´s the wrong priority to spend developing time implement a gimmick like faceplates (which is nothing more than a "nice to have") as long as the main app doesn´t behave as it should...

For me, it´s a 100% sure and again for me only logical decision:
I will not touch Waveform (or update to a new version) again as long as these basic problems aren´t solved...

As much as I like many many of the offered features... this is a no-go...
I tried long time to get used to it, but no way... as soon as I work a bit in another DAW, I start smilig a nd feel home again... Yeah... the spacebar works!!!!

But that´s me... do you whatever you want

[chico.co.uk]

Everybody else was able to manage this problem (without any noticeable problems for the user) so I stay with that point...

That you've noticed, personally. That's quite different to there not being "any noticeable problems for the user".

People post issues on here that I've never seen before, all the time. That's what testing is for. You not seeing an issue is great. But you're one user.

To suggest why this could cause issues, some plugins run as separate exes, in task manager, if you look.

Among the challenges of using low level calls, to grab keyboard focus from other apps, when you're not supposed to have it, is that people run local firewalls and similar software on their laptops, which try to prevent other apps capturing keyboard strokes, when that app doesn't have focus. To guard against things like key loggers running on the same machine.

This is to prevent things like a virus logging your internet banking details, or passwords for other websites, as you type them into a web browser, when the browser has focus. So if you implement a feature where you steal keyboard focus, some users will find other third party apps don't like that, and you're then into "why don't my Waveform keyboard shortcuts work, when I'm running Norton etc" type support calls, and troubleshooting those issues.

It isn't as straightforward as you think, life's like that sometimes.

[fromwithin]

The DAW has no way of knowing that a key has been pressed if the plugin is in focus unless the plugin explicitly chooses to return them.

Good explanation but this sentence is not true. There are low-level methods to capture keyboard/mouse events. As stated above this can lead to another class of errors and problems but technically is possible and often used.

I know that there are, but it might as well be true because of the complexity of doing it any other way, not least because rather than having a one common message loop implementation, you will have a different low-level hack for each supported platform.

[Trancit]

Everybody else was able to manage this problem (without any noticeable problems for the user) so I stay with that point...

That you've noticed, personally. That's quite different to there not being "any noticeable problems for the user".

People post issues on here that I've never seen before, all the time. That's what testing is for. You not seeing an issue is great. But you're one user.

To suggest why this could cause issues, some plugins run as separate exes, in task manager, if you look.

Among the challenges of using low level calls, to grab keyboard focus from other apps, when you're not supposed to have it, is that people run local firewalls and similar software on their laptops, which try to prevent other apps capturing keyboard strokes, when that app doesn't have focus. To guard against things like key loggers running on the same machine.

This is to prevent things like a virus logging your internet banking details, or passwords for other websites, as you type them into a web browser, when the browser has focus. So if you implement a feature where you steal keyboard focus, some users will find other third party apps don't like that, and you're then into "why don't my Waveform keyboard shortcuts work, when I'm running Norton etc" type support calls, and troubleshooting those issues.

It isn't as straightforward as you think, life's like that sometimes.

Ok, I say it different:

I´ve never seen any bug reports/ problems user had, where it turned out, that keyboard "manipulations" where the reason for that in the official forums of Cockos (Reaper), Ableton or Image-Line...

Again for me, it´s proof enough, that there are perhaps problems in theory but not in the real world...
And perhaps, there are other methods to realize this task... in the other DAWs it just works...

[dRowAudio]

To be honest, this has only popped up a couple of times over the years. We obviously prioritise things based on user feedback and my impression has been that this isn't an issue for the majority of people. Whether that's because they're using plugins that don't exhibit the behaviour or because they simply don't mind clicking on the window header to get space to work I don't know.

Is it all keystrokes that are being stolen by the plugin or just common ones like spacebar? If you assign start/stop to something more specific (like "alt + shift + s"), does that get through?

It just feels like this should work without us having to add hacks like constantly stealing back keyboard focus to our window. What happens if you have this enabled and you're trying to write some text in a plugin? You wouldn't be able to type more than a couple of characters...

[AGreen]

Is it all keystrokes that are being stolen by the plugin or just common ones like spacebar? If you assign start/stop to something more specific (like "alt + shift + s"), does that get through?

I can report that assigning start/stop to another key combination works. I'm currently using CTRL + Spacebar and it works with plugin windows that normally block the spacebar. So an effective and easy workaround.

[Trancit]

Is it all keystrokes that are being stolen by the plugin or just common ones like spacebar? If you assign start/stop to something more specific (like "alt + shift + s"), does that get through?

This I tried already and here on my side, the keyboard is completely blocked ... nothing passes the plugins I tested...

[PierreG]

For what it's worth.

Re-mapping start/sop to Ctrl Spacebar didn't work for me either.

My experiment was on the Newfangled Punctuate VST, which normally exhibits a sort of in-between behavior where pressing the space bar when the focus is inside the plug's GUI glitches playback with every press as if it's passing along the spacebar stop code to W (causing the glitch), yet it immediately starts again. Clicking on the plug's header works to restore proper start/stop functionality.

I have other plugs that exhibit this same behavior.