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

[Javier Serrano Polo]

The vocoder plug-in is included upstream of swh-plugins. It should be
packaged in a new version of swh-plugins; I have filed
https://bugs.debian.org/824211 . Let us wait some days for an answer.


smime.p7s
Description: S/MIME cryptographic signature

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

[Javier Serrano Polo]

Here it is the discussion:
https://github.com/LMMS/lmms/issues/2731

We do not get any compromise about a stable set of standardized plugins.
There is no point in sharing the plugins from LMMS, since there is
nothing specific to the project. One exception is vocoder, which does
not seem to get into swh-plugins.
https://github.com/LMMS/lmms/issues/2366

Calf LADSPA plugins are not packaged in Debian.

I would ship vocoder in vocoder-ladspa, the Calf plugins in calf-ladspa
and use /usr/lib/ladspa like all the other LADSPA packages, forgetting
multi-arch.


smime.p7s
Description: S/MIME cryptographic signature

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

[Petter Reinholdtsen]

While I agree that convenience copies should be avoided, I also believe
the upstream authors goal of portability have its virtues too.  It is
vital for building a community around lmms community that the files
created by lmms can be shared by default, and I believe we in Debian do
best if we help them with this.

When that it said, I also believe we would do well if we made it
possible, but not the default, to use all LADSPA plugins in Debian in an
lmms project, even if it would make the project incompatible with other
lmms installations, as long as this option would not be enabled by
mistake by some unsuspecting user.

I have no real experience using lmms, and prefer trust the upstream
developers to make good decisions.  After all, we need a good
relationship with upstream.

> I could help writing an upgrade_*() method to automatically upgrade
> projects, but this should be discussed with upstream.

Yes, it definitely need to be discussed with upstream.
-- 
Happy hacking
Petter Reinholdtsen

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

[Javier Serrano Polo]

Debian has a policy that should be followed about not using conveniece
copies of code. There are many packages providing LADSPA plugins that
can enhance LMMS.
https://packages.debian.org/sid/ladspa-plugin

In my humble opinion, the goal should not be to render projects the same
in different environments. This is the same problem with MIDI songs
without distributing the samples. The goal should be that the demo songs
sound good everywhere, to entice the users into composing new songs, and
to provide the best tools available. I believe that using CAPS 0.9 is a
better user experience than using CAPS 0.4. I have listened three "cool
songs" without LADSPA effects and they still sound cool.

If LMMS developers want to provide a standardized set of sound effects,
they should take care of this set. They should stick with CAPS 0.4.x in
a separate library and provide a how-to to manually upgrade old projects
(uncompress and replace strings); you cannot easily distinguish projects
using 0.4 from ones using 0.9. These separate libraries should be
installed in /usr/lib//ladspa.

I could help writing an upgrade_*() method to automatically upgrade
projects, but this should be discussed with upstream.


smime.p7s
Description: S/MIME cryptographic signature

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  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//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?

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

[Petter Reinholdtsen]

[Antonio Ospite]
> Hi Petter,
>
> about the duplication, the proper solution would be to coordinate
> with the other Debian maintainers, which can be hard.

Well, it would not be that hard, as we can always fall back to just
install plugin  as -lmms if we are unable to reach the
maintainer currently installing .

> The Debian alternatives system could provide a workaround, but I am no
> expert about it.

We could use diverts too, but neither seem like a better idea than
coordination and renaming.
> 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.

I agree that /usr/lib//ladspa is a good idea.  Are there
other programs using that location?  I guess someone with time and
contacts should get in touch with the ladspa community and try to get
acceptance for the idea there, to get it in the official specification
or something.

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

Can you write a proposal explaining how you believe Debian packages
using LADSPA should behave regarding directory locations, and put it in
wiki.debian.org somewhere?  It would provide a good starting point for
solving this issue globally, both as a reference text and as a
discussion starter.  It is probably a good idea to have non-Debian linux
distributions in mind too.

-- 
Happy hacking
Petter Reinholdtsen

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

[Tobias Doerffel]

Hi,

as one of the former main developers of LMMS I'd like to write a few
words about LMMS and LADSPA. LMMS ships a bundle of LADSPA plugins in
order to provide a standardized set of sound effects. Standardized
means, the set is the same on every platform and distribution. When
users create projects with LMMS and use our bundled plugins, it's
guaranteed that the project will work and sound the same everywhere.
If you decide to drop our plugins and depend on a package which
formally provides the same file it can still happen that things are
different and do not work as expected due to version differences.

Best example: CAPS LADSPA plugins. We have been shipping CAPS 0.4.x
for years now and the available plugins and their behaviour remained
stable for the users all the time. If you would depend on
https://packages.debian.org/jessie/caps instead, lots of effects would
be missing when loading a project as the available plugins inside CAPS
have changed significantly between 0.4.x and 0.9.x. If you'd simply
rename caps.so to caps-lmms.so no plugins would be loaded at all as
the library base name (caps) is saved in the project file (internally
we load caps.so, caps.dll or caps.dylib depending on the platform). If
we (LMMS developers) decide to switch to 0.9.x we will implement an
according upgrade mechanism internally (and probably even still
provide CAPS 0.4.x in a separate library) so things don't break for
the user.

So please help us to provide an optimal user experience for LMMS users
on Debian. Don't break LMMS by removing files from an LMMS
installation even though I understand that redundancy is bad. If you
have questions, feel free to ask.

Best regards

Toby

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

[Petter Reinholdtsen]

[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.  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//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,

-- 
Happy hacking
Petter Reinholdtsen

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

[Antonio Ospite]

Package: lmms
Version: 1.0.0-1
Severity: wishlist

Dear Maintainer,

lmms provides quite a few LADSPA plugins, what about making them
available to other programs too?

Other programs look for LADSPA plugins in some standard location like
for instance /usr/lib/ladspa, if the plugins provided by lmms were
reachable from there they could be shared with those other programs.

For example I wanted to use the vocoder plugin with GStreamer or with
Audacity, in order to do that it was enough to create a symlink to the
shared object in the aforementioned location:

  $ ln -s /usr/lib/x86_64-linux-gnu/lmms/ladspa/vocoder_1337.so /usr/lib/ladspa

Now GStreamer finds the plugin:

  $ gst-inspect-1.0 ladspa | grep vocoder
ladspa-vocoder-1337-so-vocoder-lmms: Vocoder for LMMS

Maybe as a long term solution an lmms-plugins package could be created
putting the shared objects in /usr/lib/ladspa and have lmms look for
them in there.

Similar packages exist already, you can see them with apt-file:

  $ apt-file search /usr/lib/ladspa/

I don't know if this will play nicely with multi-arch, and there will be
some conflicts if plugins with the same name are provided by different
packages, but it's still worth considering IMHO.

Thanks,
   Antonio

-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (900, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.16.0-ao2 (SMP w/1 CPU core)
Locale: LANG=it_IT.utf8, LC_CTYPE=it_IT.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages lmms depends on:
ii  libasound21.0.28-1
ii  libc6 2.19-9
ii  libfftw3-single3  3.3.4-1
ii  libfluidsynth11.1.6-2
ii  libfontconfig12.11.0-6.1
ii  libgcc1   1:4.9.1-8
ii  libjack0 [libjack-0.116]  1:0.124.1+20140122git5013bed0-3
ii  libogg0   1.3.2-1
ii  libportaudio2 19+svn20140130-1
ii  libpulse0 5.0-6
ii  libqt4-xml4:4.8.6+git49-gbc62005+dfsg-1
ii  libqtcore44:4.8.6+git49-gbc62005+dfsg-1
ii  libqtgui4 4:4.8.6+git49-gbc62005+dfsg-1
ii  libsamplerate00.1.8-8
ii  libsdl1.2debian   1.2.15-10
ii  libsndfile1   1.0.25-9
ii  libstdc++64.9.1-8
ii  libstk0c2a4.4.4-5+b1
ii  libvorbis0a   1.3.2-1.4
ii  libvorbisenc2 1.3.2-1.4
ii  libvorbisfile31.3.2-1.4
ii  libx11-6  2:1.6.2-3
ii  libxext6  2:1.3.2-1
ii  libxft2   2.3.2-1
ii  libxinerama1  2:1.1.3-1
ii  lmms-common   1.0.0-1
ii  stk   4.4.4-5+b1
ii  zlib1g1:1.2.8.dfsg-2

Versions of packages lmms recommends:
ii  caps 0.9.23-1
ii  tap-plugins  0.7.3-1

Versions of packages lmms suggests:
pn  fil-plugins none
ii  fluid-soundfont-gm  3.1-5
ii  freepats20060219-1
pn  mcp-plugins none
pn  omins   none

-- no debconf information
-- 
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?


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org