Linux public beta (4408)

[mevla]

Hello,

Would it be possible in a next update on all plugins that has multi-line text entries when saving patches, to take into account the Linux linefeeds so that the text is actually easily readable ? Currently the linefeed are shown as '\n' which results in a single long line.

It would be useful to be able to enter actual multi-line comments in both description and usage fields. Especially when learning a synth such as Bazille and saving many example/test patches and taking notes. Also useful for any other plugin.

Cheers.

bazilleNewLines.png

[Beamboom]

I got a question regarding the files packed for each plugin:
It seems to be two 64 bit versions of each plugin, one that has an additional "avx" in the filename. What is the difference between the two, and do I need both?

I see Alex' script only links to the avx-files in ~/.vst and ~/.vst3.

[abique]

The avx version uses more recent Intel instructions.

[Beamboom]

Thanks Abique! Ergo I can delete the other if the avx version works, then.

The Bitwig 2 beta currently lists both 64bit versions in the device browsers and I'd love to clean up the interface - especially if I don't need the non-avx anyways.

[glokraw]

Hi, some video issues showing up, Mint 17, intel video chip
same in Zebra, Diva, ACE, Filterscape, Hive etc:

Scaling is OK with Bitwig

Qtractor segfaults when adjusting gui size up or down

In Mixbus, plugins resize smaller OK, but not at larger than normal,
there is a large portion of the window filled in with black
on the right, and below, the visible portions.

Someone reported this at the Mixbus forum,
no public reply in 2 weeks...so I checked, and can confirm...

This is on a mediocre Intel motherboard chip, circa 2012.
(don't know what video the other poster has)Any clues?
Cheers

[glokraw]

Switched testing setup from Mint 17 to a pclinuxos with kernel 4.8.12,
and Zebra2 in qtractor scales properly,

but in Mixbus, the right-mouse-click to open
the gui-scaling dialog produces nothing, except this terminal output,
for each attempt:

AM_ViewMan::handleMouseDown
AM_ViewMan::addUndoObject inUndoObject == 0: 0
validateUndo
currentUndoObject->__end( true ) == false
undoObject Change Parameter reports invalid!
MouseUp Without Tracking
failed to read menu output: Resource temporarily unavailable

(after a few seconds, the following is added to the message)

actually writing state to /home/me/234/234.tmp
renaming state to /home/me/234/234.pending
------------------------------------------------------------

where 234 is the name of the mixbus session.

Cheers

[glokraw]

Here is terminal output to compare, from right-clicking Zebra for gui scaling,
in Mixbus, compared to Qtractor:

Mixbus output, where
'test' is the name of the Mixbus session:

actually writing state to /home/me/test/test.tmp
renaming state to /home/me/test/test.pending
AM_ViewMan::handleMouseDown
AM_ViewMan::addUndoObject inUndoObject == 0: 0
validateUndo
currentUndoObject->__end( true ) == false
undoObject Change Parameter reports invalid!
MouseUp Without Tracking
failed to read menu output: Resource temporarily unavailable

qtractor output:

AM_ViewMan::handleMouseDown
AM_ViewMan::addUndoObject inUndoObject == 0: 0
validateUndo
currentUndoObject->__end( true ) == false
undoObject Change Parameter reports invalid!
MouseUp Without Tracking
poll failed: Interrupted system call
X11 ConfigureNotify

----------------------------------------
inxi -G states:

$ inxi -G
Graphics: Card: Intel 2nd Generation Core Processor Family Integrated Graphics Controller
Display Server: X.Org 1.18.4 drivers: v4l,intel
Resolution: 1280x1024@60.02hz
GLX Renderer: Mesa DRI Intel Sandybridge Desktop
GLX Version: 3.0 Mesa 13.0.3

kernel is 4.8.12

[AVLinux]

Hi,

Just a warning of potential trouble ahead, there are changes in the xcb backend of the latest libcairo (sorry I don't know the exact version number yet) that will affect U-he plugin UI's negatively. This latest version of libcairo is not in most mainline distros yet but I recently came across this issue in recent post Ardour 5.6 releases, they had updated libcairo in their custom GTK build stack and for me the U-he GUI's became slow and CPU usage tripled. Upon troubleshooting on #ardour IRC it was determined that there had been important changes in the xcb backend of libcairo and to be very general (I'm not a developer) the U-he UI calls were now occurring in multiple places causing the CPU usage to be far too high and causing the UI's to respond slowly. As usual with libcairo issues this may not affect all video hardware, in my case I'm using an older nVidia GT9600 with the nouveau Xorg drivers and an RT kernel and the problem rendered the UI's unusable.

The Ardour devs determined that their build stack could be rolled back for the time being and for now the post 5.8.54 nightly Ardour builds are now on the older libcairo version and U-he UI's work once again (for affected users), also thanks to x42 this literal last second change was included in Mixbus 4.

To be clear Ardour/Mixbus have done their part to avert current problems but once Distribution start adopting this version of libcairo this problem will affect U-he in other Linux hosts that use Distribution versions of libcairo. This problem affects a small use case now, so I'm posting to help abique/U-he get prepared and be aware it exists, hopefully future updated Linux builds of the plugins can be provided at some point, the 4408 builds are now of a significant age and it's surprising there have not been more issues like this.

I think the Ardour devs would be more than willing to provide the exact version info of the offending version of libcairo, I'm not a developer so I don't know the details of their build stack.

Just passing this along, HUGE thanks to ALL partners in getting U-he up and running on Linux, I personally use Satin and Presswerk and at this point could not imagine production without them..

Glen MacArthur - AV Linux maintainer

[abique]

Hi,

Thank you for the warning. Do you think this regression could be considered as a bug? And so reported to the cairo team as well?

Thanks,
Alex.

[glokraw]

I have Gmac's 5.35 reaper release, and libcairo2 1.14.8-1, with the U-he plugins
working 'perfect', scaling larger/smaller, docking/undocking, and widgets widgeting

Zebra2 had to be loaded from the reaper VST list,
not it's instrument list.

on pclinuxos kernel 4.8.12 libcairo2 1.14.8-1

At the moment, I have
ACE, Bazille, Discovery Pro, Hive, Protoverb, TyrellN6, TripleCheese, and Zebra2
all loaded in reaper 5.35, dockable, scalable, gui's working, and daring the cpu,
while idling at 8.6% in qjackctl

This on an old intel motherboard video chip,
4 core, 8 threads i7@ 3.4ghz

Hope this helps, you guys are awesome!

[x42]

Hi,

Thank you for the warning. Do you think this regression could be considered as a bug? And so reported to the cairo team as well?

Thanks,
Alex.

Hi Alex,

I have not tracked it down yet, only some last minute investigation to narrow things down: cairo-1.14.4 or later when compiled with xcb-surface backend feature results in a what seems a live-loop when the plugin UI is opened. Things are fine with cairo-1.14.2 + xcb.

A shot in the dark: "xlib-xcb: Don't be lazy and use the real xcb_screen_t" (from https://www.cairographics.org/news/cairo-1.14.4/). but that's just a guess. Oddly enough other plugins using cairo are not affected. So it seems this is something specific to the u-he plugin UI and/or how the UI and Host (Mixbus) interact.

Anyway, I suggest to just statically the u-he plugin UIs and not depend on system-wide libs at all (except for libc, libX11/xcb), compare for example what the u-he plugins on windows do, no external libs safe for the core-system ones. Simply don't leave these things up to the system.

Cheers!

[x42]

Here is terminal output to compare, from right-clicking Zebra for gui scaling,
in Mixbus, compared to Qtractor:
[...snip..]

Looks like the known issue regarding context-menus. see the earlier post on this thread for a workaround:
viewtopic.php?f=31&t=424953&start=810#p6617245

[Arnd]

Hi,

Just a warning of potential trouble ahead, there are changes in the xcb backend of the latest libcairo (sorry I don't know the exact version number yet) that will affect U-he plugin UI's negatively. [...]

Hi Glen,

thanks a lot for this explanation! I stumbled across this very problem on Saturday when opening an Ardour project after upgrading from Ardour 5.5 to 5.8. The u-he Presswerk standard (complete) UI was completely unusable (UI parts missing, no redrawing after reopening the UI, no reaction to mouse events, ...), some of the other (simpler) views were very slow. After upgrading to nightly 5.8.64 everything works again.

Regards, Arnd

[Penguinum-tea]

Hello again and thank you for porting great plugins.
I think there can be a bug that doesn't allow you to register purchased Zebra 2 (at least, didn't buy others yet) plugin if the username consists of cyrillic letters and spaces (name + surname). Yes, it's kind of weird, but it was automatically assigned.
When I try to register the plugin, the host crashes. If I use 'fake' username that consists only of cyrillic letters or latin letters + spaces host doesn't crash. The 'dialog.64' utility itself runs fine.
Here is a little info about hosts:
Carla complains about floating point exception.
Tracktion7 just crashes silently.
About Ardour5... well, it doesn't show registration dialog at all.

I don't think this problem is distro/CPU/*-specific, but I'll provide extra information if needed.

[AVLinux]

Hi,

Just a warning of potential trouble ahead, there are changes in the xcb backend of the latest libcairo (sorry I don't know the exact version number yet) that will affect U-he plugin UI's negatively. [...]

Hi Glen,

thanks a lot for this explanation! I stumbled across this very problem on Saturday when opening an Ardour project after upgrading from Ardour 5.5 to 5.8. The u-he Presswerk standard (complete) UI was completely unusable (UI parts missing, no redrawing after reopening the UI, no reaction to mouse events, ...), some of the other (simpler) views were very slow. After upgrading to nightly 5.8.64 everything works again.

Regards, Arnd

Hi Arnd,

Thanks for confirming that, good to know it has shown up somewhere else, these things can be very frustrating for the poor developers to figure out when they don't appear consistently. As far as Ardour and Mixbus the real thanks go to x42 and Paul for their quick response to the bug report and willingness to revert the stack..