Re: [fluid-dev] Bundling ladspa.h

[Tom M.]

> I'm proposing to bundle the compile-time dependency (i.e. the ladspa.h header 
> file) with FluidSynth

I vote against it. Even if it's only a single header file, bundling it
with fluidsynth would mean to fork LADSPA. Look at with the people at
MuseScore did with fluidsynth: In 2012 (when fluidsynth was already
pretty inactive for a couple of months) they also bundled fluidsynth
with their software and rewrote it in C++. Now fluidsynth is active
again and the guys at MuseScore wont profit from any further upstream
development. Also if there are any bugs regarding fluidsynth, they
will have to cope with them by themselves, it's not the same
fluidsynth anymore as we are developing.

And the same could happen with LADSPA. Sure development is inactive
since... wow 2007. But you never know whether they start developing
tomorrow (introducing many many more header files ;) ). Bundling
ladspa with fluidsynth could sooner or later lead to introducing
custom fixes, adoptions, etc. until we are incompatible with ladspa
upstream...


> As I see it, the only thing that might be a problem is the dependency on 
> gmodule. When LADSPA is always compiled it, FluidSynth requires not only glib 
> and gthread, but also the gmodule. But as all three libs are part of the glib 
> distribution, that doesn't seem a huge problem to me.

For me and you this might not be a problem, but for ReinholdH @
NotationSoftware it probably would be. They sell their software
(including fluidsynth + glib) to people that dont have fast internet
these days. They will probably not be amused if their download takes
even longer, just for a dependency library that ultimately they dont
even need (...ok gmodule is only 15KiB, but you get my point?)


Looking forward to hearing any other opinions
Tom


2017-11-13 10:02 GMT+01:00 Marcus Weseloh <address@hidden>:
> Hi all,
>
> as the LADSPA subsystem has been cleaned up and has been shown to also work
> on WIndows, I'm proposing to bundle the compile-time dependency (i.e. the
> ladspa.h header file) with FluidSynth and remove the compile-time switches
> and "#ifdef LADSPA" from the codebase.
>
> LADSPA isn't actively developed anymore, the header file has been unchanged
> for a number of years. And quite a few other open-source projects also
> include the LADSPA header file in their codebase, for example Ardour and
> Audacity do that. Bundling it and removing the #ifdefs reduce complexity,
> both for developers and end-users.
>
> LADSPA should still stay disabled by default, in which case the performance
> impact of this change would be two additional (if synth->ladspa_fx != NULL)
> for each rendered block. And the LADSPA subsystem only allocates memory when
> it is enabled. It will increase the size of the library a little bit, but I
> don't think that is realy a problem. We add new code to FluidSynth in other
> places as well.
>
> As I see it, the only thing that might be a problem is the dependency on
> gmodule. When LADSPA is always compiled it, FluidSynth requires not only
> glib and gthread, but also the gmodule. But as all three libs are part of
> the glib distribution, that doesn't seem a huge problem to me.
>
> So I would really like to get your feedback on this. Is there any reason not
> to bundle ladspa.h and always compiling it for all platforms?
>
> Cheers,
>
>     Marcus
>
> _______________________________________________
> fluid-dev mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/fluid-dev
>