Cannot move dials in Bitwig 3

[VOXLmotiondesign]

In KDE (on X11):

In KDE System Settings/Windows Management/Window Rules, you can create a Window-rule for each u-He plugin (Window matching/Window title/Substring match/<name>. Set Appearance & Fixes/Accept focus to 'Force' and 'No'.

[fsciarra62]

Hi all,
I don't know if this topic is still of interest... I forgot to post my personal experience on this.
Seen it has been bumped back, I profit (or Prophet... ok .... sorry)
I'm currently on Ubuntustudio 19.10, which is based on Xfce (on Xorg).
And lately upgraded to Bitwig 3.1beta2.
Up to now, I never experienced the behavior you mentioned.
I mean, I've always been able to move controls in U-He applications since my first buy in 2018 on ubuntustudio 18.04 (then 19.04 and now 19.10).

By the way I'm experiencing left mouse click not working in X-AIR-EDIT for my Behringer XR18 since a couple of weeks: I have to use right and central click... Very strange. It doesn't happen with enlightenment e20, same computer, same configuration.
Best regards,
Fabrizio

[HeadDesk]

Any movement on this? I'm also plagued by this bug. Have tried the latest Linux build of Zebra. Interestingly, it's not just Bitwig that Zebra does this in, Reaper on Linux also has Zebra behaving this way.

[z15]

I wonder if it's something Window Manager specific? I have build 8256 (what was, at least a couple of days ago, the latest "official" build) of Zebra 2 and Bitwig 3.1.3, and everything is working as it should - left click dragging knobs to adjust values works fine, so does the right click context menu.

(Running a customized installation on Xorg, i3WM, so I don't know how much this helps, but at least everything works OK on latest Bitwig Studio and recent Z2 build so...)

[mevla]

I'm certainly not upgrading to Bitwig 3.x until there are clear signals that this problem is solved. In any case, not that I need another modular synth (already got Bazille). Last thing I want to do with this currently completely functional music setup is to chase solutions to induced problems. Also, since Bitwig does not support running plugins using wine-staging and linvst, 3.x might introduce a problem regarding this and then, no way to get help from Bitwig.

It works now, why fix it ?

Cheers.

[fsciarra62]

Dear Mevla,
I've just updated to ubuntu studio 20.04 beta (wait until April 23 for a stable release) and Bitwig to 3.2beta2 and my u-he plugins work perfectly using the mouse. I have all of them, so I've tried all for you.
Just beware that FilterScape, TripleCheese, and Uhbik are still to be updated. So they do not work properly as VST3. MIDI learn doesn't work for them in VST3.
Midi learn works in all VST2 versions and all the other vst3.
For all of them in any version, Bitwig modulation works properly using the device parameters.
Hope this helps.
Fabrizio
PS. Version 3.2 contains new toys like eq+ and expanded color concept. And stuff. Check it out if you have an active plan. And you get a discount on u-he products if you buy Bitwig now.

PPS. I'm using Carla to run windows plugins in Bitwig and works great on 19.10.
I have some Eventide plugins and Melodyne studio working well.
The 20.04 beta is giving me some headaches because the iLok manager doesn't connect to the iLok site. So I can only use the plugins I already have or boot on the 19.10... Well... I just got Anthology XI which is in free demo for 90 days so it's enough.

[mevla]

Thanks Fabrizio for the reply. It's nice to hear that things works in that case. I use Xubuntu 18.04, so there's already a difference in the desktop, if it matters. I use VST2 only so far. Although I greatly use u-he synths as goto synths, I have several Windows plugins that adds other colours and textures, not to mention the money put into them. As such I still do not feel it to be a good move to upgrade to 3.x since Bitwig offers no support for Windows plugins under Linux. They actually recommend to use Window for Windows plugins.

And so everything is working now in 2.4.3, with linvst. I'm very very hesitant to disrupt this nice setup for the unknown aspects. If it was possible to install two versions of Bitwig in parallel, I could give it a try. That would be the best way to try it out. But that's not possible as far as I know. Maybe the Bitwig team could give it a thought and enable doing this. Why scrap a previous well-running setup when wanting to upgrade to a new Bitwig version ? I'm asking the question and I don't even make money with music. Imagine people making money with this tool, would they be keen to throw away a setup just for the sake of upgrading ? I guess they have several hardware computer setups.

[HeadDesk]

I've figured it out on my end. It was my keyboard layout. If I have my Polish layout enabled, I cannot move the dials. If I delete my layouts file ($ rm .config/xfce4/xfconf/xfce-perchannel-xml/keyboard-layout.xml ), then I can once again move the dials in Zebra. For all you guys having this issue, try deleting any custom keyboard layouts and their associated config files.

[Kyran]

In KDE (on X11):

In KDE System Settings/Windows Management/Window Rules, you can create a Window-rule for each u-He plugin (Window matching/Window title/Substring match/<name>. Set Appearance & Fixes/Accept focus to 'Force' and 'No'.

I'm not sure how you found this out, but this does fix the issue for me on my production machine.

It may be worth pointing out that I only have this issue with vst 3 plugins.

[kresbeatz]

I had the same issue with not moving dials. When I change my keyboard layout to English (I'm using three different languages in my system) every u-he plugin work as it should, but as soon as I change my keyboard layout to something not English (tried with Hungarian and Russian) I can't move the dials immediately. So the temporary workaround is just change your layout to English when working with Bitwig. However, it will be good if they can fix this annoying bug, I hope it is not much work

PS Triend on last Bitwig and fully updated PopOS 20.04, Ubuntu 20.04 and Manjaro 20.1 Gnome

[eras]

The last solution of switching to US keyboard layout solved the problem for me on Debian Bullseye. I don't run KDE so KDE-specific solutions did not apply.

I doubt this is an issue in Bitwig (now at version 4), because as far as I understand, it doesn't really handle the GUI side of the plugin: the plugin does that directly. It's probably an issue with the plugin itself, but as Bitwig on Linux is probably one of the most popular VST hosts around, people discussing the problem are most visible in that context.

All in all I cannot understand how it's possible to create this kind of bug but I am also surprised that it hasn't been fixed for such a long time given how it seems like it's very easy to reproduce.

Well, at least the workaround works. Thanks kresbeatz!

[glokraw]

Install the reaper demo, and see if you can reproduce the issue.

https://www.reaper.fm/download.php

Create a folder like .636 in /home/you

and unarchive the download there. Then move the contents
out of the new folder into the .636 folder, and start reaper in a terminal,

$ .636/reaper

[eras]

I installed Reaper and then tried the Zebra2 plugin (both VST2 and VST3i in Reaper's lists).

The result is the same as in Bitwig: it was not possible to turn the knobs if I used the Finnish or EurKey keyboard layout, but if I switched to US keyboard layout, they worked fine.

[glokraw]

Thanks for taking time to do that, as it further points
to the heart of the issue.
Cheers

[jarkko]

Hi, I did a summary of this issue: viewtopic.php?f=292&t=576419. Hope this helps! Looking at the thread this does not reveal much new tho, expect that the bug is DAW agnostic and likely xinput specific. With Wayland it never triggers.