depend on external swh ladspa plugins instead of embedding the code

[andrewrk]

It looks like lmms is embedding code from this project: https://github.com/swh/ladspa

Looks like that project has an xml file with embedded C; in lmms the C is embedded directly into lmms source code. Instead of doing that can we depend on the external package?

Here's the package in Ubuntu:

andy@desktop:~$ apt-cache show swh-plugins 
Package: swh-plugins
Priority: optional
Section: universe/sound
Installed-Size: 2026
Maintainer: Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com>
Original-Maintainer: Debian Multimedia Maintainers <pkg-multimedia-maintainers@lists.alioth.debian.org>
Architecture: amd64
Version: 0.4.15+1-7
Provides: ladspa-plugin
Depends: libc6 (>= 2.15), libfftw3-single3
Filename: pool/universe/s/swh-plugins/swh-plugins_0.4.15+1-7_amd64.deb
Size: 691672
MD5sum: b06b5d2c7fe377daac6bb3a8d9a4c516
SHA1: a0501bae822af84a95b71e514d89217b1f9ff0e5
SHA256: 7dad8b5d148e242f42e31c6c9cb3c544352d51ea281cf85f001965e1cdc4338f
Description-en: Steve Harris's LADSPA plugins
 Steve Harris has written a large number of plugins for LADSPA
 compatible hosts (e.g. GLAME, Sweep and ecasound). The plugins
 available are:
 .
 amp, fast overdrive, overdrive (with colourisation), comb filter,
 waveshaper, ringmod, divider, diode, decliper, pitch scaler,
 16 band equaliser, sinus wavewrapper, hermes filter, chorus,
 flanger, decimater, oscillator, gverb, phasers, harmonic generators,
 surround encoders and more.
Description-md5: eae8bed900bb978b2c2eeb41c2f8acb9
Homepage: http://plugin.org.uk/
Description-md5: eae8bed900bb978b2c2eeb41c2f8acb9
Bugs: https://bugs.launchpad.net/ubuntu/+filebug
Origin: Ubuntu
Task: ubuntustudio-video, ubuntustudio-audio

Looks like debian has the package as well: http://packages.debian.org/sid/swh-plugins

I'll make a pull request for it; I just wanted to make sure I'm not missing something here.

[andrewrk]

Better yet - if we support lv2 we could depend on this package:

swh-lv2 - Steve Harris's SWH plugins ported to LV2

And then delete all this crazy C code from lmms.

[tobydox]

There were and are good reasons to include and ship with all these plugins. By far not all distributions ship all LADSPA packages and even if, they're partly outdated. Furthermore most of the plugins are not available for Windows so that's why we include them in our build so the end user always gets a huge collection of nice plugins, on whatever platform or distribution he is and we don't have lots of work to build them for every platform manually. It's party of the all-in-one-concept - installing all kind of dependencies manually sucks.

Distributions are free in shipping LMMS without particular LADSPA plugins (by setting CMake flag WANT_SWH etc. or not including according *.so files) and depend on the external package.

Anyways feel free to implement proper LV2 support ;-)

[andrewrk]

Ah that makes sense. Thanks for the explanation.

[dobey]

There are better ways to bundle plug-ins for Windows than to embed them all in the source tree. Bundling them in the source tree does nothing useful for lmms itself, but to constantly introduce build problems, and induce a maintenance burden on developers.

For Windows, those plug-ins could be pulled from appropriate places and simply included in the installer (or zip file, I don't know how you're distributing Windows builds exactly). This would avoid having the code in the lmms tree, and allow bundling them with lmms itself for those users.

You could also do binary bundling by building an installer for Linux as well, for general distribution by the lmms project itself (so you then avoid also building distribution-specific packages), and let distributions who include lmms to build their own packages.

[tobydox]

I have to disagree here. The LADSPA plugins never caused any serious build problems as they do not have other/extra dependencies and also do not depend on the LMMS plugin API. This makes them very easy to maintain. If distributions do not want to include them, they can configure this when invoking cmake. As the plugins rarely see updates (if at all) the maintainance effort is low also from this perspective.

Picking Win32 binaries built somewhen somehow by somebody (if available at all) is a lot of work too and also does introduce additional problems like ABI incompatibilities, additional runtime dependencies etc. If we build them as part of LMMS, we can always be sure, that they're up to date and built with the same and latest compiler technology/toolchain (possibly also providing better optimized code). Last but not least: try to find 64 bit DLLs for all the LADSPA plugins. Same for all other architectures/platforms other than Linux x86/x86_64.

[eagles051387]

Hey Tobyy I notice you mention the plugin API it would be great if we could get a gui front end to interface with it. Is this something which is being planned?

On Tue, Feb 11, 2014 at 12:56 PM, Tobias Doerffel notifications@github.comwrote:

I have to disagree here. The LADSPA plugins never caused any serious build problems as they do not have other/extra dependencies and also do not depend on the LMMS plugin API. This makes them very easy to maintain. If distributions do not want to include them, they can configure this when invoking cmake. As the plugins rarely see updates (if at all) the maintainance effort is low also from this perspective.

Picking Win32 binaries built somewhen somehow by somebody (if available at all) is a lot of work too and also does introduce additional problems like ABI incompatibilities, additional runtime dependencies etc. If we build them as part of LMMS, we can always be sure, that they're up to date and built with the same and latest compiler technology/toolchain (possibly also providing better optimized code). Last but not least: try to find 64 bit DLLs for all the LADSPA plugins. Same for all other architectures/platforms other than Linux x86/x86_64.

Reply to this email directly or view it on GitHubhttps://github.com/LMMS/lmms/issues/96#issuecomment-34747698 .

Jonathan Aquilina

[dobey]

@tobydox There's no reason you can't build the plug-ins from an external source when building the Windows installer. You don't have to grab pre-built binaries. But you can always grab the latest version from upstream, rather than whatever you happen to have imported in lmms.

[tobydox]

Of course you could build them externally but that would make the build process complicated. For building the Win32/Win64 installer currently all you have to do is to run the "build_mingw32" script and "make package". The upstream plugins all have different build systems, partially even incomplete MinGW/cross-compiling support etc. The integrated versions have been unified regarding build system and are working well.

Nevertheless we can discuss endless here - however as I'm the person maintaining both the plugins and the Windows build chain, it's my decision to save me lots of work by doing things just the way I've been doing them the last years.