Linux public beta (4408)

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

Post

Penguinum-tea wrote: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.
Hi,

As far as Ardour5 goes you may not be able to see the registration dialog and some other gtk3 menus in the U-he plugins without running a script on your system first. Look back at the bottom of page 55 and top of 56 of this forum thread to find the script and info.
Top

Post

A quick heads up: I've noticed that the u-he VSTs report CanDo "bypass", but the actual call to effSetBypass returns 0, and the plugin is not bypassed. The Presswerk Linux VST, for example. Is that a bug, or am I missing something?
Top

Post

AVLinux wrote:Look back at the bottom of page 55 and top of 56 of this forum thread to find the script and info.
Hi
The script worked, thank you. Now the window appears and Ardour crashes too. The only string it prints right before crash is "watched PID no longer exists - releasing device."
Top

Post

In Harrison Mixbus 4, I have implemented the recommended quick fix (so the SAVE dialogue works correctly) but it seems that all u-he plugins ignore the keyboard controls in their main window. For example, I am unable to switch the patches using up / down arrow keys. This is the case even when I activate the specific Mixbus icon in the top right corner, which should enable passing the keystrokes to the plugin.

EDIT: I originally mentioned page up / down keys. I meant to write "up / down arrows".
Last edited by fuxoft on Thu Mar 09, 2017 2:44 pm, edited 1 time in total.
Top

Post

Penguinum-tea wrote: The only string it prints right before crash is "watched PID no longer exists - releasing device."
That is a message from Ardour's ALSA backend. When Ardour terminates it release the lock soundcard, so that pulseaudio can return. Unrelated to the issue.
Top

Post

Man.... you are great :!:
Linux is the future...lets invest in it..yeah!! :party:
:clap: :clap: :clap: :clap:
:pray:
Top

Post

abique, should I wait for updates or ask u-he for new username and key?
Penguinum-tea wrote:I think there can be a bug that doesn't allow you to register purchased Zebra 2 plugin if the username consists of cyrillic letters and spaces (name + surname).
Top

Post

Penguinum, ask them that might be faster/better.
Top

Post

abique wrote:Penguinum, ask them that might be faster/better.
Just discovered that the problem also appears in Windows version of plugin (running in Wine), so I should have written them first. Excuse my disturbing you.
Top

Post

x42 wrote:
abique wrote: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.
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.
One step further. Here's a backtrace showing cairo using libX11-xcb. The u-he GUI (here presswerk) background thread takes 100% of one CPU core in the following section.

Code: Select all

Thread 34 (Thread 0x7fff837fe700 (LWP 29293)):
#0  0x00007fffed698d5d in writev () at ../sysdeps/unix/syscall-template.S:84
#1  0x00007fffec02141d in ?? () from /usr/lib/x86_64-linux-gnu/libxcb.so.1
#2  0x00007fffec02181d in ?? () from /usr/lib/x86_64-linux-gnu/libxcb.so.1
#3  0x00007fffec021fc3 in xcb_send_request_with_fds64 () from /usr/lib/x86_64-linux-gnu/libxcb.so.1
#4  0x00007fffec022129 in xcb_send_request () from /usr/lib/x86_64-linux-gnu/libxcb.so.1
#5  0x00007fffec02e1c8 in xcb_put_image () from /usr/lib/x86_64-linux-gnu/libxcb.so.1
#6  0x00007ffff371a752 in ?? () from /opt/Ardour-5.8.138/lib/libcairo.so.2
#7  0x00007ffff371faea in ?? () from /opt/Ardour-5.8.138/lib/libcairo.so.2
#8  0x00007ffff3722ca1 in ?? () from /opt/Ardour-5.8.138/lib/libcairo.so.2
#9  0x00007ffff37289c7 in ?? () from /opt/Ardour-5.8.138/lib/libcairo.so.2
#10 0x00007ffff367b919 in ?? () from /opt/Ardour-5.8.138/lib/libcairo.so.2
#11 0x00007ffff36e6155 in ?? () from /opt/Ardour-5.8.138/lib/libcairo.so.2
#12 0x00007ffff36e6155 in ?? () from /opt/Ardour-5.8.138/lib/libcairo.so.2
#13 0x00007ffff36847d8 in ?? () from /opt/Ardour-5.8.138/lib/libcairo.so.2
#14 0x00007ffff367e839 in ?? () from /opt/Ardour-5.8.138/lib/libcairo.so.2
#15 0x00007ffff36745ba in cairo_paint_with_alpha () from /opt/Ardour-5.8.138/lib/libcairo.so.2
#16 0x00007fff91db3028 in ?? () from /home/tester/.vst/u-he/Presswerk.64.so
#17 0x00007fff91cf8006 in ?? () from /home/tester/.vst/u-he/Presswerk.64.so
#18 0x00007fff91cb69e8 in ?? () from /home/tester/.vst/u-he/Presswerk.64.so
#19 0x00007fff91cf759c in ?? () from /home/tester/.vst/u-he/Presswerk.64.so
#20 0x00007fff91cf7de1 in ?? () from /home/tester/.vst/u-he/Presswerk.64.so
#21 0x00007fff91d5271a in ?? () from /home/tester/.vst/u-he/Presswerk.64.so
#22 0x00007fff91d50003 in ?? () from /home/tester/.vst/u-he/Presswerk.64.so
#23 0x00007fff91db0372 in ?? () from /home/tester/.vst/u-he/Presswerk.64.so
#24 0x00007fff91dbfa69 in ?? () from /home/tester/.vst/u-he/Presswerk.64.so
#25 0x00007ffff099f424 in start_thread (arg=0x7fff837fe700) at pthread_create.c:333
#26 0x00007fffed6a09bf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:105
It's one of the 3 background threads started by the GUI (I suspect the meter/compressor-curve animations in Presswerk). The main rendering thread is fine and the GUI shows correctly initially.

Debian's libcairo is not linked against x11-xcb and does not exhibit this problem. I don't know about other distributions.

Dependent libs (debian vs ardour-stack):

Code: Select all

$ LD_LIBRARY_PATH=/opt/Ardour-5.8.138/lib/  ldd /opt/Ardour-5.8.138/lib/libcairo.so.2 
	linux-vdso.so.1 (0x00007ffccd5d1000)
	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f55cd195000)
	libpixman-1.so.0 => /opt/Ardour-5.8.138/lib/libpixman-1.so.0 (0x00007f55ccec0000)
	libfontconfig.so.1 => /opt/Ardour-5.8.138/lib/libfontconfig.so.1 (0x00007f55ccc73000)
	libfreetype.so.6 => /opt/Ardour-5.8.138/lib/libfreetype.so.6 (0x00007f55cc9d2000)
	libpng16.so.16 => /opt/Ardour-5.8.138/lib/libpng16.so.16 (0x00007f55cc794000)
	libxcb-shm.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-shm.so.0 (0x00007f55cc58e000)
	libX11-xcb.so.1 => /usr/lib/x86_64-linux-gnu/libX11-xcb.so.1 (0x00007f55cc38c000)
	libxcb.so.1 => /usr/lib/x86_64-linux-gnu/libxcb.so.1 (0x00007f55cc164000)                        #<<<<<<<<<
	libxcb-render.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-render.so.0 (0x00007f55cbf56000)
	libXrender.so.1 => /usr/lib/x86_64-linux-gnu/libXrender.so.1 (0x00007f55cbd4c000)
	libX11.so.6 => /usr/lib/x86_64-linux-gnu/libX11.so.6 (0x00007f55cba0c000)
	libXext.so.6 => /usr/lib/x86_64-linux-gnu/libXext.so.6 (0x00007f55cb7f8000)
	libz.so.1 => /opt/Ardour-5.8.138/lib/libz.so.1 (0x00007f55cb5df000)
	librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f55cb3d7000)
	libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f55cb0d3000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f55cad35000)
	/lib64/ld-linux-x86-64.so.2 (0x000056457cc8b000)
	libexpat.so.1 => /opt/Ardour-5.8.138/lib/libexpat.so.1 (0x00007f55cab07000)
	libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f55ca901000)
	libXau.so.6 => /usr/lib/x86_64-linux-gnu/libXau.so.6 (0x00007f55ca6fd000)
	libXdmcp.so.6 => /usr/lib/x86_64-linux-gnu/libXdmcp.so.6 (0x00007f55ca4f7000)

# vs debian's one

$ LD_LIBRARY_PATH=/opt/Ardour-5.8.138/lib/  ldd /usr/lib/x86_64-linux-gnu/libcairo.so
	linux-vdso.so.1 (0x00007fff932d6000)
	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f0d23b33000)
	libpixman-1.so.0 => /opt/Ardour-5.8.138/lib/libpixman-1.so.0 (0x00007f0d2385e000)
	libfontconfig.so.1 => /opt/Ardour-5.8.138/lib/libfontconfig.so.1 (0x00007f0d23611000)
	libfreetype.so.6 => /opt/Ardour-5.8.138/lib/libfreetype.so.6 (0x00007f0d23370000)
	libpng16.so.16 => /opt/Ardour-5.8.138/lib/libpng16.so.16 (0x00007f0d23132000)
	libxcb-shm.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-shm.so.0 (0x00007f0d22f2c000)
	libxcb.so.1 => /usr/lib/x86_64-linux-gnu/libxcb.so.1 (0x00007f0d22d04000)
	libxcb-render.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-render.so.0 (0x00007f0d22af6000)
	libXrender.so.1 => /usr/lib/x86_64-linux-gnu/libXrender.so.1 (0x00007f0d228ec000)
	libX11.so.6 => /usr/lib/x86_64-linux-gnu/libX11.so.6 (0x00007f0d225ac000)
	libXext.so.6 => /usr/lib/x86_64-linux-gnu/libXext.so.6 (0x00007f0d2239a000)
	libz.so.1 => /opt/Ardour-5.8.138/lib/libz.so.1 (0x00007f0d2217f000)
	librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f0d21f77000)
	libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f0d21c73000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f0d218d5000)
	/lib64/ld-linux-x86-64.so.2 (0x000055f15cd2a000)
	libexpat.so.1 => /opt/Ardour-5.8.138/lib/libexpat.so.1 (0x00007f0d216a7000)
	libXau.so.6 => /usr/lib/x86_64-linux-gnu/libXau.so.6 (0x00007f0d214a3000)
	libXdmcp.so.6 => /usr/lib/x86_64-linux-gnu/libXdmcp.so.6 (0x00007f0d2129b000)
	libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f0d21097000)
I've just changed the libcairo we ship with Ardour/Mixbus to compile with `--enable-xlib --enable-xcb-shm --disable-xlib-xcb` and the problem also goes away. Then again this may result in an overall performance penalty (previously we've used "--enable-xlib-xcb --enable-xcb-shm").

This smells like a concurrency issue in the plugin (x11-xcb works fine otherwise for other plugins and the host itself).

I still think that the plugins should be statically linked (ship your own cairo) and have no external dependencies which can vary depending on user's system and plugin-host. If you need help with that, I'll gladly volunteer.
Top

Post

I don't think that we will statically link to cairo.
The benefit of dynamic linking is that the user can use the implementation that he chooses for cairo, which should be the best for his system, it could include latest fixes and optimizations.
If cairo has a regression, it should be fixed by cairo right?
Also I can't imagine a distribution shipping a version of cairo which could completely slowdown a desktop.

On Archlinux we have cairo-1.14.8-1 and it seems to be fine.

I believe that you are using the latest one? 1.15.4?
Top

Post

abique wrote:I don't think that we will statically link to cairo.
The benefit of dynamic linking is that the user can use the implementation that he chooses for cairo, which should be the best for his system
Can you elaborate how to make this decision?
It's the plugin's rendering code that uses libcairo's API not the user. Also there are no guarantees about the ABI stability of libcairo. -- How can I find out which version and configuration of cairo is best for the u-he plugins on a given system? What is the minimum API requirement?
abique wrote: If cairo has a regression, it should be fixed by cairo right?
Right. It's hard to say if it's a regression though. So far only the u-he plugin UIs exhibit this issue, and I cannot inspect the code. Judging from some gdb backtraces I'd hazard a guess that some call that are blocking in XLib are asynchronous in XCB and the plugin UI keeps rendering nonstop.
abique wrote: I believe that you are using the latest one? 1.15.4?
No, see above 0.14.8. The problem appears in since cairo 0.14.4 or later when compiled with --enable-xlib-xcb. Upstream cairo started to extend the direct xcb surface support after 0.14.2.
Top

Post

Speaking of cairo/x11.. how does one trigger a resize?

Choosing a different ui-scale the plugin logs "X11 ConfigureNotify", the container window resizes, the UI and cairo-surface of the plugin scales, but the draw function does not reset the clipping: It retains the cairo_clip() from the time when the window was first mapped.

Code: Select all

...
AM_VST_Editor::getRect 960 x 660
AM_ViewMan::handleMouseDown
currentUndoObject == NULL
MouseUp Without Tracking
audioMasterSizeWindow 1152 792                                       #<< debug msg from Ardour
LXVSTPluginUI::resize_callback 1152 x 792                            #<< debug msg from Ardour
dispatch_x_events: ConfigureNotify cfg:(1152 792) plugin:(1152 792)  #<< debug msg from Ardour
X11 ConfigureNotify
...
xwminfo confirms the window (and all childs) are resized:

Code: Select all

$ xwininfo -tree

xwininfo: Window id: 0x5a00c6b "Audio: Presswerk (by u-he)"

  Root window id: 0xe7 (the root window) (has no name)
  Parent window id: 0x166074e (has no name)
     2 children:
     0x5a00c6e (has no name): ()  1152x792+10+43  +422+68
        1 child:
        0x5200001 (has no name): ()  1152x792+0+0  +422+68
           1 child:
           0x5c00001 (has no name): ()  1152x792+0+0  +422+68
     0x5a00c6c (has no name): ()  1x1+-1+-1  +411+24
Yet, `cairo-trace` shows the presswerk-gui still uses previous cairo-clip rectangle:

Code: Select all

...
save
n 0 0 960 660 rectangle
clip
...
A work-around is to change the preference to 200% and only scale down, then cairo-clip just remains large enough: 1920x1320.

Any hints why that may be? Is there a specific X-event which makes the UI re-query the size?

Thanks in advance.

PS. I found https://github.com/julianstorer/JUCE/co ... 55daa57ce1 but that makes no difference.
Top

Post

Hello,

I have all the new versions as per the opening of this thread. I also have Dark Zebra 3904 - is there a newer version ?

Thanks !
Top

Post

Is it due to Cairo mismatch that for instance Satin (have not tested others yet) is not possible to register or change preferences in its GUI since mouse input is ignored and right click for scaling does nothing ?

Running Ardour 5.8 Build 203 on Fedora 24 -64 Gnome

Installed Cairo stuff

cairo.i686 1.14.8-1.fc24 @updates
cairo.x86_64 1.14.8-1.fc24 @updates
cairo-gobject.x86_64 1.14.8-1.fc24 @updates
cairomm.x86_64 1.12.0-2.fc24 @fedora
pycairo.x86_64 1.10.0-4.fc24 @fedora
python3-cairo.x86_64 1.10.0-15.fc24 @fedora

From my non-dev corner it looks like having a matched local Cairo lib included in the U-he plugin is getting more and more crucial and possibly not avoidable.

Best regards aHellquist
x42 wrote:
abique wrote:I don't think that we will statically link to cairo.
The benefit of dynamic linking is that the user can use the implementation that he chooses for cairo, which should be the best for his system
Can you elaborate how to make this decision?
It's the plugin's rendering code that uses libcairo's API not the user. Also there are no guarantees about the ABI stability of libcairo. -- How can I find out which version and configuration of cairo is best for the u-he plugins on a given system? What is the minimum API requirement?
abique wrote: If cairo has a regression, it should be fixed by cairo right?
Right. It's hard to say if it's a regression though. So far only the u-he plugin UIs exhibit this issue, and I cannot inspect the code. Judging from some gdb backtraces I'd hazard a guess that some call that are blocking in XLib are asynchronous in XCB and the plugin UI keeps rendering nonstop.
abique wrote: I believe that you are using the latest one? 1.15.4?
No, see above 0.14.8. The problem appears in since cairo 0.14.4 or later when compiled with --enable-xlib-xcb. Upstream cairo started to extend the direct xcb surface support after 0.14.2.
Top
Locked

Return to “u-he”