Bug#758888: lmms: Provide links to LADSPA plugins in /usr/lib/ladspa

[Antonio Ospite]

On Mon, 21 Sep 2015 19:51:05 +0200
Petter Reinholdtsen <pere at 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?