Linux public beta (4408)

Official support for: u-he.com
Locked New Topic
RELATED
PRODUCTS

Post

OK, them I'm happy that it is working for you now.
The u-he plugins should not take long to scan.

Post

mr.ardour wrote:@beamboom: no, it's more a case of good luck that the method used to show menus etc. just happens to work with some DAWs/hosts and not with others. What is going on here has nothing to do with any plugin API standard, and everything to do with an extremely unconventional approach to the problem of "how do I get my plugin GUI to show a menu?". The solution used (so far) is to create an entirely new program to show the menu, which then relies on the window stacking behaviour of the window manager in question, which then relies on the window hinting behaviour of each DAW/host.
Luck is rarely a factor when it comes to software behaviour. ;)
I see your point but I'd still say it's the DAW that is to blame here, due to the role of a DAW: A DAW is a playground where lots of toys shall reside and thrive. And as such it should strive to support valid design choices from these toys. I can't see how this is related to the window manager when it works with some hosts and not others on that same manager.

The responsibility of a plugin is to follow protocol and adhere to the defined standards/APIs. That's done here as far as I can see. So ultimately, in this case I stand by my opinion to point the finger at the DAW.

... Not that it helps any Ardour users, of course. I do hope this'll work out for you!

Post

Mixbus 3.7 came out a few days ago and now all u-he plugins crash mixbus for me. It went from having some GUI issues to crashing whenever I interact with a plugin.

It would be interesting to know if this is just my setup or if other mixbus users are having crashes after updating to 3.7.

Post

Repo-1 seems to be working fine in Ardour 5.4 on Fedora 24 :)

I am having a problem that using a Wacom tablet i can't click to enter the beta serial number, I also can't click to change any of the preferences.

The same problem in Beatzille, i can't change anything like mode:poly and voices:6. I double tap and drag, and try left and right click and nothing happens.

Does anyone know if this is a Linux issue, a Wacom driver issues, an Ardour issue, or a U-He plugin issues? THANKS!

Post

hi there at U-HE!

I always loved the sound of your plug-ins. but porting them to linux is just awesome.
pls keep the linux paved path. because of this I will spend more money on U-HE plug-ins!

next buy Hive and then Zebra2

best wolfgang

Post

Overmann wrote:Mixbus 3.7 came out a few days ago and now all u-he plugins crash mixbus for me. It went from having some GUI issues to crashing whenever I interact with a plugin.

It would be interesting to know if this is just my setup or if other mixbus users are having crashes after updating to 3.7.
Do you have a backtrace?
I would suggest to bisect ardour and find out which change did introduce the crash, that might give us an insight on the issue.

Post

David Else wrote:Repo-1 seems to be working fine in Ardour 5.4 on Fedora 24 :)

I am having a problem that using a Wacom tablet i can't click to enter the beta serial number, I also can't click to change any of the preferences.

The same problem in Beatzille, i can't change anything like mode:poly and voices:6. I double tap and drag, and try left and right click and nothing happens.

Does anyone know if this is a Linux issue, a Wacom driver issues, an Ardour issue, or a U-He plugin issues? THANKS!
Hello,

I have not tried u-he plugins on Linux with a wacom tablet or a touchscreen, because I have none of them :)

I would have thought that the display server would translate the touch/pen interaction into regular mouse event if the window does not tell X11 that it supports touch/pen events.

A workaround when the menu are not working is to use the mouse wheel over the control.

I hope that helps.

Post

abique wrote:
Hello,

I have not tried u-he plugins on Linux with a wacom tablet or a touchscreen, because I have none of them :)

I would have thought that the display server would translate the touch/pen interaction into regular mouse event if the window does not tell X11 that it supports touch/pen events.

A workaround when the menu are not working is to use the mouse wheel over the control.

I hope that helps.
I don't have a mouse wheel! :lol:

This is getting very frustrating. Please could you tell me exactly what input is expected in the preferences area in Repo-1? Maybe we can work this out.

Every other thing in Repo-1 work 100% with the tablet apart from the window where I enter the serial and the preferences.

Can i enter my serial in a config file instead?

For example preferences/default size 100%... I double click, left click, right click and I can't enter or change anything? What type of click does this control expect? THANKS!

Post

David, I would suggest something very simple, install Renoise or Bitwig (both in demo mode is enough). Qtractor 0.7.9 also worked here.

From there you can create patches, register, everything!

The license is stored as text in ~/.u-he/Repro-1/Support/com.u-he.Repro-1.user.txt for Repro-1.

Post

abique wrote:David, I would suggest something very simple, install Renoise or Bitwig (both in demo mode is enough). Qtractor 0.7.9 also worked here.

From there you can create patches, register, everything!

The license is stored as text in ~/.u-he/Repro-1/Support/com.u-he.Repro-1.user.txt for Repro-1.
Thanks for the idea to try to register in other software. It would be much better if i could just use a valid "com.u-he.Repro-1.user.txt for Repro-1." file. It does not exist yet on my machine, if you would be really kind and link me a valid file with the beta test serial in then I can use it again when I register and use the commercial serial :)

User Name: "Beta Tester"
Serial Number: "V9574-NOL2Q-FUIUA-GQG8"

If you could tell me exactly what kind of mouse input is expected I can do some research to see if my Wacom driver is dodgy, or Fedora is doing something funny. I really don't want to install any more software. Also, the problem is affecting usability and I want to use Ardour, which seems awesome!

Post

David Else wrote:
abique wrote:David, I would suggest something very simple, install Renoise or Bitwig (both in demo mode is enough). Qtractor 0.7.9 also worked here.

From there you can create patches, register, everything!

The license is stored as text in ~/.u-he/Repro-1/Support/com.u-he.Repro-1.user.txt for Repro-1.
Thanks for the idea to try to register in other software. It would be much better if i could just use a valid "com.u-he.Repro-1.user.txt for Repro-1." file. It does not exist yet on my machine, if you would be really kind and link me a valid file with the beta test serial in then I can use it again when I register and use the commercial serial :)

User Name: "Beta Tester"
Serial Number: "V9574-NOL2Q-FUIUA-GQG8"

If you could tell me exactly what kind of mouse input is expected I can do some research to see if my Wacom driver is dodgy, or Fedora is doing something funny. I really don't want to install any more software. Also, the problem is affecting usability and I want to use Ardour, which seems awesome!
UPDATE! It all works OK in the renoise demo! Hope you can get it fixed for Ardour users.

Since Mich Murder uses renoise i will give it a try and consider switching :love:

Post

One don't have to use Renoise or Bitwig for registering and editing patches in the u-he products when they don't work as expected in the Ardour based hosts. Carla from kxstudio is a wonderful plugin host and everything is ok from there.

Post

We (Glen from AVLinux and I) just got to the bottom of the Ardour/Mixbus issue that affects some u-he Linux users.

Ardour & Mixbus bundle a couple of libraries and set an environment variable to prefer those libraries over the system-wide installed ones. For context-menus, the u-he plugins launch an external gtk3 application which does rely on system-wide libraries and this results in a conflict.

Until the issue is properly resolved, the following one-liner can work around it

Code: Select all

sh -c "$(curl -s -L https://git.io/vX7ne)"
That line downloads a shell script and runs it. The script renames and wraps all the u-he dialog application to unset the environment. (it's safe to run it repeatedly)

Post

Cool... thanks Glen and R !
You can't always get what you waaaant...

Post

x42 wrote:We (Glen from AVLinux and I) just got to the bottom of the Ardour/Mixbus issue that affects some u-he Linux users.

Ardour & Mixbus bundle a couple of libraries and set an environment variable to prefer those libraries over the system-wide installed ones. For context-menus, the u-he plugins launch an external gtk3 application which does rely on system-wide libraries and this results in a conflict.

Until the issue is properly resolved, the following one-liner can work around it

Code: Select all

sh -c "$(curl -s -L https://git.io/vX7ne)"
That line downloads a shell script and runs it. The script renames and wraps all the u-he dialog application to unset the environment. (it's safe to run it repeatedly)
Thank you for the diagnostic of the issue!
Please can you inline your script instead of doing some sh -c "$(curl ....)" which almost gave me an heart attack (security).

Thank you very much.

Locked

Return to “u-he”