Good Morning,
Toby the upstream dev read the above reasons and would like to thank you
for a detailed explination as to why resid and zynsubaddfx need to be
bundled and why the system versions could not be used.
Thanks
Jonathan
On Sun, Apr 27, 2014 at 11:10 AM, Tobias Doerffel <[email protected]
> wrote:
> Hi,
>
> 2014-04-27 9:47 GMT+02:00 Jonathan Aquilina <[email protected]>:
> > here is the reason that gentoo doesnt like bundled software
> >
> > https://wiki.gentoo.org/wiki/Why_not_bundle_dependencies
>
>
> These are good reasons but we are having good (better) reasons as
> well. First of all, we're not bundling ZynAddSubFX but integrating it.
> That's a huge difference both from a technical view and from the
> user's perspective. ZynAddSubFX is not a shared library making it
> impossible to link against it. However we need to link against it in
> order to integrate it (i.e. call the functions for fetching the sound
> data, sending MIDI events/controllers, pitch wheel bend range update
> etc.). That's only possible by compiling in the sources. Furthermore
> we need to modify the sources for proper integration, e.g. disabling
> the confirmation-dialog at exit. Otherwise you would always have to
> confirm to close the ZASF GUI whenever you hide it (when removing
> track, unloading project, clicking the "Show/hide GUI"). Furthermore
> we use our own Qt-based XML backend so the original mxml library is
> not required.
>
> In order to be able to use an external ZASF, they would have to move
> everything into a shared library and make the ZynAddSubFX binary just
> a minimal binary with a main() function which calls the according
> functions from the library. At the same time the headers would have to
> be provided as an SDK (-> libzynaddsubfx and libzynaddsubfx-dev).
>
> I can't say anything about resid but I'd guess it could be a difficult
> dependency as not all distributions have it.
>
> Regarding the LADSPA plugins: there's the possibility to exclude them
> from build however this leads to the major problems that the LMMS
> userbase does not use the same plugins and/or the same versions. One
> good example: CAPS. There's the 0.4.x series and the new 0.9.x series.
> Both of them are not compatible, many plugins inside got renamed,
> removed or added. In LMMS we have the 0.4.x series which has been
> working well for years. If a distribution decides to remove our
> caps.so and depend on their own CAPS 0.9 package instead (which is
> present in e.g. Debian Stable, Ubuntu 14.04 etc.), the user definitly
> won't be able to properly open and play back older or external
> projects as he will be missing lots of plugins even though he has
> CAPS. This functional break could even result from a simple package or
> system update where LMMS itself isn't touched!
>
> That's why I'm still in favor of bundling integral parts of LMMS so
> they're strictly under our control and the users get the best possible
> experience and compatibility. (for the CAPS problem we can build a
> smart upgrade path somewhen later and even provide the old CAPS
> library for compatibility)
>
> Toby
>
--
Jonathan Aquilina
------------------------------------------------------------------------------
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos. Get
unparalleled scalability from the best Selenium testing platform available.
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs
_______________________________________________
LMMS-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/lmms-devel
