I upgraded Bitwig from 3.1.3 to 3.2.4 and now it seems all the U-He plugins can't get window focus, so all key presses are registred on the host (Bitwig) and not in the plugin. So I can't browse presets using arrow keys anymore, I need to click with the mouse.
This applies to all the U-He plugins I tried (I have most of them), all the same: Arrow keys pressed changes channel/panel etc on Bitwig in the background, not in the plugin.
I have tried OTHER 3rd party plugins (Pianoteq, the Loomer ones) and they worked like before, so oddly enough this seem to only affect the U-he plugins.
Anyone else experience this? Is it a known issue?
No window focus? (Bitwig 3.2.4)
-
- KVRian
- 1111 posts since 6 Jul, 2009
probably related to this :
* Plug-ins can no longer steal focus whenever the mouse moves over the plug-in window (e.g., LiquidSonics Reverberate 2), but we eventually give in to avoid fighting over window focus forever.
* Plug-ins can no longer steal focus whenever the mouse moves over the plug-in window (e.g., LiquidSonics Reverberate 2), but we eventually give in to avoid fighting over window focus forever.
-
- KVRist
- Topic Starter
- 208 posts since 2 Apr, 2014
Ah - that's from the Bitwig changelog? You may quite possibly be right, thanks a lot! I'll include this in a message to Bitwig support.paulbreeze wrote: ↑Sat Jul 04, 2020 12:54 pm probably related to this :
* Plug-ins can no longer steal focus whenever the mouse moves over the plug-in window (e.g., LiquidSonics Reverberate 2), but we eventually give in to avoid fighting over window focus forever.
-
- KVRian
- 1111 posts since 6 Jul, 2009
-
- KVRist
- Topic Starter
- 208 posts since 2 Apr, 2014
Nope - this is introduced in 3.2.
Next up I guess I could try a different window manager, xfce, just for the hell of it. But it DOES work on Gnome in all versions prior to 3.2, and really it should, since Gnome is the default interface on Ubuntu now.
Next up I guess I could try a different window manager, xfce, just for the hell of it. But it DOES work on Gnome in all versions prior to 3.2, and really it should, since Gnome is the default interface on Ubuntu now.
-
tasmaniandevil tasmaniandevil https://www.kvraudio.com/forum/memberlist.php?mode=viewprofile&u=62450
- KVRAF
- 1731 posts since 22 Mar, 2005 from a planet called u-he
Just tested and I can confirm this.
It was working fine in version 3.1, but not anymore in version 3.2.4.
The changelog for Bitwig version 3.2 included this:
I'll try to ask Alex about it, but it might take a while to get an answer.
It was working fine in version 3.1, but not anymore in version 3.2.4.
The changelog for Bitwig version 3.2 included this:
I guess that's what's causing this problem.Linux: When plug-in window is focused, allow key events to still work as though the Bitwig window was focused (for example, keyboard note input will still work)
I'll try to ask Alex about it, but it might take a while to get an answer.
That QA guy from planet u-he.
-
- KVRist
- Topic Starter
- 208 posts since 2 Apr, 2014
Oh - that must indeed be it. Thanks for checking it out. I sincerely hope this can be corrected soon.tasmaniandevil wrote: ↑Mon Jul 06, 2020 8:48 am The changelog for Bitwig version 3.2 included this:I guess that's what's causing this problem.Linux: When plug-in window is focused, allow key events to still work as though the Bitwig window was focused (for example, keyboard note input will still work)
I'll try to ask Alex about it, but it might take a while to get an answer.
-
- KVRist
- Topic Starter
- 208 posts since 2 Apr, 2014
Here's a reply I received on Facebook just now:
"This is actually a bug in U-he plug-ins that they are aware of and working on a fix. It only affects Linux. The problem is due to them never asking for keyboard input focus. It used to work in 3.1 because we had a bug where we used the default focus mechanism of the X server (where it sends keyboard input to the window under the mouse). You will notice in 3.1 it stops working for example if the mouse is moved outside of the plugin window. We had to stop using this default mode to fix these focus problems due to position of the mouse and also allow the keyboard to be used for note input if desired. However for plugins that never asked for keyboard input there is then suddenly no way that they can get it. Hopefully u-he will have a fix soon."
"This is actually a bug in U-he plug-ins that they are aware of and working on a fix. It only affects Linux. The problem is due to them never asking for keyboard input focus. It used to work in 3.1 because we had a bug where we used the default focus mechanism of the X server (where it sends keyboard input to the window under the mouse). You will notice in 3.1 it stops working for example if the mouse is moved outside of the plugin window. We had to stop using this default mode to fix these focus problems due to position of the mouse and also allow the keyboard to be used for note input if desired. However for plugins that never asked for keyboard input there is then suddenly no way that they can get it. Hopefully u-he will have a fix soon."
-
- KVRist
- 133 posts since 10 Aug, 2017
Oh, I'd be delighted if this is a u-he thing that will be fixed!
I don't use Bitwig, but if I understand this correctly, it might be the same issue that occurs in Mixbus (32c).
I've actually written a post about it with no replies: http://mixbus.harrisonconsoles.com/foru ... -9064.html
However in Qtractor everything works as it should.
I don't use Bitwig, but if I understand this correctly, it might be the same issue that occurs in Mixbus (32c).
I've actually written a post about it with no replies: http://mixbus.harrisonconsoles.com/foru ... -9064.html
However in Qtractor everything works as it should.
-
tasmaniandevil tasmaniandevil https://www.kvraudio.com/forum/memberlist.php?mode=viewprofile&u=62450
- KVRAF
- 1731 posts since 22 Mar, 2005 from a planet called u-he
If it's a problem in the Linux plugins on our side then I'm sure Alex will fix it as soon as he finds the time.
That QA guy from planet u-he.
-
- KVRist
- Topic Starter
- 208 posts since 2 Apr, 2014
It looks to be the *exact* same issue indeed. It's actually a relief for me to see it's not just Bitwig who's affected by this. And yeah, incredibly annoying to not be able to use the arrow keys! Such a minor thing perhaps, but dang how cumbersome.krans wrote: ↑Wed Jul 08, 2020 12:39 pm if I understand this correctly, it might be the same issue that occurs in Mixbus (32c).
I've actually written a post about it with no replies: http://mixbus.harrisonconsoles.com/foru ... -9064.html
-
- KVRist
- Topic Starter
- 208 posts since 2 Apr, 2014
Latest on this matter (from Facebook, written by developer Nicholas Allen):
"I've found a good workaround on our side now actually so no need for u-he to fix anything. Fix should make it into the 3.2.5 release. If plug-in does not request focus still forward any key events to it that we receive but don't want to do anything with."
"I've found a good workaround on our side now actually so no need for u-he to fix anything. Fix should make it into the 3.2.5 release. If plug-in does not request focus still forward any key events to it that we receive but don't want to do anything with."
