EE decided that plugins are not installed even though they are

[v-fox]

EasyEffects Version

6.2.7+60~git20220725.e89188ae

What package are you using?

openSUSE

Distribution

Tumbleweed (rolling)

Describe the bug

Suddenly, after a recent update EE started treating all Cald and LSP output effects as perpetually bypassed. Turns out, it drops is not installed and port symbol not found in G_MESSAGES_DEBUG=easyeffects for all of them even though they did not go anywhere.

Expected Behavior

Not lose plugins and also indicate "absent" state in UI rather than silently bypassing.

Debug Log

No response

Additional Information

Maybe this has something to do with update to lv2-devel-1.18.6 and liblilv-devel-0.24.16 ? PW version is 0.3.56+46~git20220723.aab15433c

[wwmm]

Maybe this has something to do with update to lv2-devel-1.18.6 and liblilv-devel-0.24.16 ?

Probably. All the interaction with LV2 plugins is done through lilv. Here on Arch Linux I am still on lilv 0.24.14. So I don't know what kind of changes it has. I will try to look at its commits.

Not lose plugins and also indicate "absent" state in UI rather than silently bypassing.

In PulseEffects there was something in this direction but while moving from Pulseaudio to PipeWire and from GTK3 to GTK4 I forgot to add some kind of feedback about missing plugins. I will try to remember to do it.

[justanerd]

I can confirm easyeffects lv2 plugins break with lilv-0.24.16 downgrading to lilv-0.24.14 resolves the problem.

[wwmm]

As far as I could see there is no API change in lilv 0.24.16. The difference is that it now uses Meson as build system. So maybe it's package maintainers have to build it in a different way now.

[v-fox]

As far as I could see there is no API change in lilv 0.24.16. The difference is that it now uses Meson as build system. So maybe it's package maintainers have to build it in a different way now.

There isn't much ways to build that different. Would be nice if you could update your system and check your plugin search code for excessive strictness. Maybe it relies on some kind of unintended behaviour that was removed.

audacity seems to be finding them just fine. Which seem to be using same lib: rpm -q --whatrequires 'liblilv-0.so.0()(64bit)' gives audacity-3.1.3-217.2.x86_64.

UPD: duh, I kind of figured it out! For some reason it now wants to have LV2_PATH=/usr/lib64/lv2 variable set explicitly. At least for lilv's own lv2ls and EE.

[wwmm]

UPD: duh, I kind of figured it out! For some reason it now wants to have LV2_PATH=/usr/lib64/lv2 variable set explicitly. At least for lilv's own lv2ls and EE.

I wonder if this is a side effect of the lilv updates for the Apple os. Besides the changes in build system the only thing in lilv commits are changes for macos and mingw

[wwmm]

Would be nice if you could update your system and check your plugin search code for excessive strictness. Maybe it relies on some kind of unintended behaviour that was removed.

I will have to make a custom package with it. Arch Linux did not update lilv yet.

[wwmm]

Creating a custom lilv package caused more annoyances than I was expecting. But after editing the PKGBUILD from AUR https://aur.archlinux.org/packages/lilv-git I was able to make it. For some reason lilv is failing to build with docs enabled. So I had to disable them. In any case so far things are working as expected here on Arch Linux. There was no need to se any environment variables.

Now I will rebuild easyeffects with the new lilv. Maybe something changes after that.

[wwmm]

Things still work after recompiling EasyEffects. But I've noticed that here on Arch Linux LV2 plugins are not installed under /usr/lib64/lv2. The path is /usr/lib/lv2. What may be happening is that lilv is only searching inside /usr/lib/lv2 and that other paths need to be specified through LV2_PATH. I do not set any custom path. I just tell lilv to search the plugin.

[v-fox]

Creating a custom lilv package caused more annoyances than I was expecting. But after editing the PKGBUILD from AUR https://aur.archlinux.org/packages/lilv-git I was able to make it. For some reason lilv is failing to build with docs enabled. So I had to disable them.

I always preferred Gentoo's build system over Arch and rpm-based. But it fatally lacks maintainers. The build failure was probably because of some missing dependency or unexpected system path.

In any case so far things are working as expected here on Arch Linux. There was no need to se any environment variables.

Now I will rebuild easyeffects with the new lilv. Maybe something changes after that.

Things still work after recompiling EasyEffects. But I've noticed that here on Arch Linux LV2 plugins are not installed under /usr/lib64/lv2. The path is /usr/lib/lv2. What may be happening is that lilv is only searching inside /usr/lib/lv2 and that other paths need to be specified through LV2_PATH. I do not set any custom path. I just tell lilv to search the plugin.

Are you sure that Arch doesn't forcibly set LV2_PATH ? They are clearly worried about it - https://wiki.archlinux.org/title/Professional_audio#Environment_variables - so someone might have wanted to be helpful. Or 'lib' without suffix might be hardcoded into lilv. Does Arch uses lib32 for legacy binaries convention instead of lib64 as default for x86_64 ? On distros with lib64, lib also exists but for 32-bit compatibility libs, so no native lv2 plugins there.

Anyway, audacity is probably manually sets search-path. Something like "subdir 'lv2' in every libdir from ld path list" because I don't see any related settings but the list of 3rd-party plugins is full. Maybe EE should do so. Otherwise, it's not 'easy' or even intuitive.

As a personal workaround I've put this into ~/.profile:

if [ -z "$LADSPA_PATH" ]; then
    export LADSPA_PATH=/usr/lib64/ladspa
fi
if [ -z "$LV2_PATH" ]; then
    export LV2_PATH=/usr/lib64/lv2
fi

To get applied under KDE/plasma it might need to have file ~/.kde/env/default.sh with:

test -f ~/.profile  && . ~/.profile || true

[wwmm]

I always preferred Gentoo's build system over Arch and rpm-based. But it fatally lacks maintainers. The build failure was probably because of some missing dependency or unexpected system path.

Probably some missing dependency I could not understand what it was. Initially lilv wanted sphinx-build. What was in the package python-sphinx. But after that it complained about a missing lilv sphinx theme. It was almost like lilv sources were supposed to provide this theme configuration but they didn't.

Are you sure that Arch doesn't forcibly set LV2_PATH ? They are clearly worried about it - https://wiki.archlinux.org/title/Professional_audio#Environment_variables - so someone might have wanted to be helpful. Or 'lib' without suffix might be hardcoded into lilv.

At least the output of printenv does not have LV2 variables.

Does Arch uses lib32 for legacy binaries convention instead of lib64 as default for x86_64 ? On distros with lib64, lib also exists but for 32-bit compatibility libs, so no native lv2 plugins there.

On Arch Linux /usr/lib64 is just a symbolic link to /usr/lib. There is a /usr/lib32 for 32 bits libraries.

Anyway, audacity is probably manually sets search-path. Something like "subdir 'lv2' in every libdir from ld path list" because I don't see any related settings but the list of 3rd-party plugins is full. Maybe EE should do so. Otherwise, it's not 'easy' or even intuitive.

Considering the circumstances I think we will have to somehow force lilv to search on other paths too. I think that GStreamer's wrapper for lv2 does that. Later I will take a closer look at how they are doing it.