On Mon, Nov 13, 2017 at 11:09 AM, Tom M. <tom.m...@googlemail.com> wrote:
> > 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... > > That doesn't seem relevant. 1. Ladspa is set in stone. It has mostly been replaced by lv2 now. (lv2 stands for ladspa v2.) 2. ladspa.h can't change too much because then the plugins would have to be recompiled. 3. It wouldn't make sense to change ladspa.h if it was included in fluidsynth. So it wouldn't be a fork. 4. If ladspa.h "upstream" would change in a way that would force plugins to be recompiled (and this won't happen), the only required change in fluidsynth would be to update the ladspa.h file.
_______________________________________________ fluid-dev mailing list fluid-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/fluid-dev
