Login / Register  0 items | $0.00 NewWhat is KVR? Submit News Advertise

Linux public beta (4408)

User avatar
AVLinux
KVRer
 
10 posts since 15 Jul, 2014

Postby AVLinux; Mon Mar 06, 2017 6:10 pm Re: Linux public beta (4408)

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.
x42
KVRer
 
21 posts since 23 Apr, 2015

Postby x42; Tue Mar 07, 2017 3:48 am Re: Linux public beta (4408)

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?
Penguinum-tea
KVRer
 
8 posts since 16 Nov, 2014

Postby Penguinum-tea; Tue Mar 07, 2017 11:34 am Re: Linux public beta (4408)

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."
fuxoft
KVRist
 
47 posts since 28 May, 2015

Postby fuxoft; Tue Mar 07, 2017 11:50 am Re: Linux public beta (4408)

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 6:44 am, edited 1 time in total.
x42
KVRer
 
21 posts since 23 Apr, 2015

Postby x42; Tue Mar 07, 2017 12:02 pm Re: Linux public beta (4408)

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.
RO-mix
KVRist
 
52 posts since 21 Nov, 2006

Postby RO-mix; Thu Mar 09, 2017 2:01 am Re: Linux public beta (4408)

Man.... you are great :!:
Linux is the future...lets invest in it..yeah!! :party:
:clap: :clap: :clap: :clap:
:pray:
Penguinum-tea
KVRer
 
8 posts since 16 Nov, 2014

Postby Penguinum-tea; Fri Mar 10, 2017 12:31 pm Re: Linux public beta (4408)

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).
abique
KVRian
 
529 posts since 26 May, 2013, from Berlin

Postby abique; Fri Mar 10, 2017 12:33 pm Re: Linux public beta (4408)

Penguinum, ask them that might be faster/better.
Penguinum-tea
KVRer
 
8 posts since 16 Nov, 2014

Postby Penguinum-tea; Fri Mar 10, 2017 12:57 pm Re: Linux public beta (4408)

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.
x42
KVRer
 
21 posts since 23 Apr, 2015

Postby x42; Tue Mar 14, 2017 2:13 pm Re: Linux public beta (4408)

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.
abique
KVRian
 
529 posts since 26 May, 2013, from Berlin

Postby abique; Tue Mar 14, 2017 11:50 pm Re: Linux public beta (4408)

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?
x42
KVRer
 
21 posts since 23 Apr, 2015

Postby x42; Wed Mar 15, 2017 1:57 am Re: Linux public beta (4408)

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.
x42
KVRer
 
21 posts since 23 Apr, 2015

Postby x42; Wed Mar 15, 2017 7:17 am Re: Linux public beta (4408)

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.
mevla
KVRist
 
475 posts since 3 Nov, 2015

Postby mevla; Wed Mar 15, 2017 7:00 pm Re: Linux public beta (4408)

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 !
Subarumannen
KVRer
 
28 posts since 5 Nov, 2011

Postby Subarumannen; Wed Mar 22, 2017 1:34 am Re: Linux public beta (4408)

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.
PreviousNext

Moderator: u-he Mods

Return to u-he