On Mon, 21 Sep 2015 19:51:05 +0200 Petter Reinholdtsen <p...@hungry.com> wrote:
> [Antonio Ospite] > > Dear Maintainer, > > > > lmms provides quite a few LADSPA plugins, what about making them > > available to other programs too? > > Thank you for the idea. I've been wondering about this a bit lately, > and one idea was to change the lmms build to install the LADSPA > plugins in /usr/lib/ladspa/. It seemed like a good idea until I was > told that the plugins included in lmms also are included in other > packages, and might cause conflicts. > Hi Petter, about the duplication, the proper solution would be to coordinate with the other Debian maintainers, which can be hard. The Debian alternatives system could provide a workaround, but I am no expert about it. > I also realised that the /usr/lib/ladspa/ content is architecture > dependent, and adding a file there break multi-arch support. It is > thus unclear to me how to handle this in a good way. > > For example, if someone install the amd64 and i386 packages including > LADSPA plugins, which ones should show up in /usr/lib/ladspa/? They > will work for some programs and not others. One could try to store > them in /usr/lib/<arch-triplet>/ladspa/ instead, but programs > supporting the LADSPA specification will not find them there as the > specification do not mention those directories. Perhaps the best way > is to use a /etc/profile.d/ fragment to set the LADSPA_PATH > environment variable to wherever the plugins are installed, and drop > the idea of one canonical place to find them all? Freshly installed > plugin packages will only take effect after login / starting a new > shell, but at least it will handle many plugins in an multi-arch > environments. Or perhaps all programs should be started using a > wrapper sourcing LADSPA paths from a .d directory during startup? > > I welcome feedback and ideas on how to properly handle this, in a way > that work with all or most programs using LADSPA plugins, > Regarding the plugin path, my use case is to use the vocoder plugin provided by lmms with GStreamer (see http://ao2.it/109), and the ladspa element in GStreamer seems to be looking for plugins in these paths: /usr/lib/ladspa /usr/local/lib/ladspa /usr/lib/x86_64-linux-gnu/ladspa So using /usr/lib/x86_64-linux-gnu/ladspa would work for me. It also seems a reasonable approach in general. In Gstreamer the path is defined in the code at build time using LIBDIR, see http://cgit.freedesktop.org/gstreamer/gst-plugins-bad/tree/ext/ladspa/gstladspa.c#n147 #define GST_LADSPA_DEFAULT_PATH \ "/usr/lib/ladspa" G_SEARCHPATH_SEPARATOR_S \ "/usr/local/lib/ladspa" G_SEARCHPATH_SEPARATOR_S \ LIBDIR "/ladspa" So lmms too could adopt a similar strategy and put the plugins under /usr/lib/x86_64-linux-gnu/ladspa. And other debian packages can follow the same scheme if they want. To make this more formal, maybe Debian itself could specify that packages providing/using LADSPA plugins should use the multi-arch path, but I do not see myself involved in that. Thanks, Antonio -- Antonio Ospite http://ao2.it A: Because it messes up the order in which people normally read text. See http://en.wikipedia.org/wiki/Posting_style Q: Why is top-posting such a bad thing?
