x42 plugins issue with Kushview Element

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi David,

I have some issues with the gmsynth.lv2 and avldrums.lv2 packages that I'd like to report. I noticed these while testing out Kushview's latest Element version from their gitlab, but the official 0.46.6 version in extra has the same issue. The issue being that Element completely locks up when trying to instantiate these plugins.

I like both the x42 plugins (which we use a lot in my courses at JGU) and Element (which I plan to use in lieu of Carla in the future, since in my experience it has better cross-platform compatibility which is important for my students running Mac or Windows on their laptops). So I hope that the issue with those two plugins can be sorted out in some way.

The plugins do work fine in Ardour and Carla, which seem to be a little more accommodating. So I initially reported the issue upstream (see https://gitlab.com/kushview/element-external/-/issues/53), but quite frankly I don't think that Element is to blame here. A while back those plugins were changed to link against the system fluidsynth library instead of the bundled stripped-down version included in the upstream source, and that seems to cause the issue. The system fluidsynth library drags in a bunch of additional library dependencies that obviously cause problems with Element. Here they are (ldd /usr/lib/lv2/gmsynth.lv2/gmsynth.so):

        linux-vdso.so.1 (0x00007ffcbe3fd000)
        libfluidsynth.so.3 => /usr/lib/libfluidsynth.so.3 (0x00007f7806f48000)
        libc.so.6 => /usr/lib/libc.so.6 (0x00007f7806d66000)
        libgomp.so.1 => /usr/lib/libgomp.so.1 (0x00007f7806d15000)
        libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0x00007f7806bc9000)
        libsndfile.so.1 => /usr/lib/libsndfile.so.1 (0x00007f7806b42000)
        libpulse-simple.so.0 => /usr/lib/libpulse-simple.so.0 (0x00007f7806b3b000)
        libpulse.so.0 => /usr/lib/libpulse.so.0 (0x00007f7806ae4000)
        libasound.so.2 => /usr/lib/libasound.so.2 (0x00007f78069f2000)
        libportaudio.so.2 => /usr/lib/libportaudio.so.2 (0x00007f78069c3000)
        libjack.so.0 => /usr/lib/libjack.so.0 (0x00007f7806984000)
        libpipewire-0.3.so.0 => /usr/lib/libpipewire-0.3.so.0 (0x00007f78068a0000)
        libdbus-1.so.3 => /usr/lib/libdbus-1.so.3 (0x00007f780684f000)
        libgmodule-2.0.so.0 => /usr/lib/libgmodule-2.0.so.0 (0x00007f7806846000)
        libinstpatch-1.0.so.2 => /usr/lib/libinstpatch-1.0.so.2 (0x00007f780678a000)
        libgobject-2.0.so.0 => /usr/lib/libgobject-2.0.so.0 (0x00007f7806728000)
        libSDL2-2.0.so.0 => /usr/lib/libSDL2-2.0.so.0 (0x00007f780654d000)
        libreadline.so.8 => /usr/lib/libreadline.so.8 (0x00007f78064f6000)
        libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007f7806200000)
        libm.so.6 => /usr/lib/libm.so.6 (0x00007f7806113000)
        libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x00007f78064cf000)
        /usr/lib64/ld-linux-x86-64.so.2 (0x00007f780705e000)
        libpcre2-8.so.0 => /usr/lib/libpcre2-8.so.0 (0x00007f7806078000)
        libogg.so.0 => /usr/lib/libogg.so.0 (0x00007f78064c4000)
        libvorbisenc.so.2 => /usr/lib/libvorbisenc.so.2 (0x00007f7805fcd000)
        libFLAC.so.12 => /usr/lib/libFLAC.so.12 (0x00007f780647c000)
        libopus.so.0 => /usr/lib/libopus.so.0 (0x00007f7805f6f000)
        libmpg123.so.0 => /usr/lib/libmpg123.so.0 (0x00007f7805f12000)
        libmp3lame.so.0 => /usr/lib/libmp3lame.so.0 (0x00007f7805e9a000)
        libvorbis.so.0 => /usr/lib/libvorbis.so.0 (0x00007f7805e6c000)
        libpulsecommon-16.1.so => /usr/lib/pulseaudio/libpulsecommon-16.1.so (0x00007f7805de5000)
        libsystemd.so.0 => /usr/lib/libsystemd.so.0 (0x00007f7805cef000)
        libffi.so.8 => /usr/lib/libffi.so.8 (0x00007f7805ce4000)
        libncursesw.so.6 => /usr/lib/libncursesw.so.6 (0x00007f7805c6d000)
        libxcb.so.1 => /usr/lib/libxcb.so.1 (0x00007f7805c42000)
        libasyncns.so.0 => /usr/lib/libasyncns.so.0 (0x00007f7805c38000)
        libcap.so.2 => /usr/lib/libcap.so.2 (0x00007f7805c2c000)
        libgcrypt.so.20 => /usr/lib/libgcrypt.so.20 (0x00007f7805ae3000)
        liblz4.so.1 => /usr/lib/liblz4.so.1 (0x00007f7805ac1000)
        liblzma.so.5 => /usr/lib/liblzma.so.5 (0x00007f7805a8e000)
        libzstd.so.1 => /usr/lib/libzstd.so.1 (0x00007f78059bb000)
        libXau.so.6 => /usr/lib/libXau.so.6 (0x00007f78059b4000)
        libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0x00007f78059ac000)
        libgpg-error.so.0 => /usr/lib/libgpg-error.so.0 (0x00007f7805986000)

For comparison, here are the ld libs in the version built straight from the upstream source:

        linux-vdso.so.1 (0x00007ffe58374000)
        libm.so.6 => /usr/lib/libm.so.6 (0x00007f094c46c000)
        libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0x00007f094c320000)
        libc.so.6 => /usr/lib/libc.so.6 (0x00007f094c13e000)
        /usr/lib64/ld-linux-x86-64.so.2 (0x00007f094c639000)
        libpcre2-8.so.0 => /usr/lib/libpcre2-8.so.0 (0x00007f094c0a3000)

I understand that in general it may be preferable to link to a system lib if available, but in this case this obviously does more harm than good. You really want your plugins to be as lean and mean as possible, and in this case they aren't. Also, Robin has just brought to my attention that the bundled source of fluidsynth is not only stripped down, but optimized for the included soundfonts (GeneralUser_LV2.sf2 in the case of gmsynth) so that they sound much better than with the stock fluidsynth, which is another reason to prefer the bundled fluidsynth.

The easiest solution IMHO is to just remove the patch that links against the system fluidsynth library in these two packages; the plugins then work fine with Element as is.

Talking about Element, I think that the official 0.46.6 package also needs some love. :) It doesn't build from source currently, as some of the requisite git repositories have gone missing (apparently when KV moved their source to gitlab), and the binary package doesn't appear to run all that well on a current pipewire-based system either. What I noticed on all of my Arch/Manjaro systems is that, even with the simplest of patches, I get an unacceptable latency between MIDI input and audio output, in the hundreds of milliseconds. I get none of that with any of the packages that I built myself (whether 0.46.6 or the latest 1.0.0 build 175), nor with the AppImage from Kushview's website, so the problem actually seems to be in the package from extra (which, if I'm not mistaken, was last rebuilt quite some time ago).

Maybe this package just needs to have the PKGBUILD updated and rebuilt. Or you could go straight to the current Element version on gitlab (1.0.0 build 175 at the time of this writing), which is much better. Maybe you can have a look at my updated PKGBUILD for the git version at https://aur.archlinux.org/packages/element-git to see how the current version can be built from the gitlab source. No doubt this needs some more work to get it into extra, but I know that you know how to deal with that. ;-)

TIA,
Albert

--
Dr. Albert Gr"af
Computer Music Research Group, JGU Mainz, Germany
Email: aggraef@xxxxxxxxx, web: https://agraef.github.io/

[Index of Archives]     [LM Sensors]     [Linux Sound]     [ALSA Users]     [ALSA Devel]     [Linux Audio Users]     [Linux Media]     [Kernel]     [Gimp]     [Yosemite News]     [Linux Media]

  Powered by Linux