> 3. It wouldn't make sense to change ladspa.h if it was included in > fluidsynth. So it wouldn't be a fork.
People tend to have fancy ideas ;) > 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. If there is **any** change to upstream ladspa.h we should update our own copy. This ofc requires an **active** maintainer who actually notices such upstream updates and cares to also update our custom copy (dont take that for granted), in worst case merging custom changes with ladspa upstream. I want to point out that I will not be that person. Furthermore I am afraid that bundling ladspa.h could be the begin of bundling even more dependencies. Another thought: bundling dependencies usually induces headache to linux packagers, because when doing a make install all those dependency headers would be installed as well. But the packager doesnt want them, because they are already provided by other packages. Thus the packager must manually clean up (i.e. mess around in) the installation to avoid file conflicts with other packages. > And the fact that projects like Ardour, Audacity and Csound all bundle their > own copy of the ladspa.h header makes me even more confident that this a good > idea. Ardour and esp. audacity really think they have to bundle each and everything... from ffmpeg to libsndfile to portmidi. And I dislike that because my experience is that all those custom changes and bug fixes they may introduce downstream usually never get back to upstream. Ardour even bundles fluidsynth 1.1.6, they still havent managed to update it... Finally I second what JJC said about modularity and independency. Tom 2017-11-13 13:20 GMT+01:00 Marcus Weseloh <mar...@weseloh.cc>: > 2017-11-13 11:33 GMT+01:00 Kjetil Matheussen <k.s.matheus...@gmail.com>: >> >> 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. > > > I second that. LADSPA development hasn't been just stalled, it is basically > "finished". As Kjetil says, all new stuff goes into LV2. > > And the fact that projects like Ardour, Audacity and Csound all bundle their > own copy of the ladspa.h header makes me even more confident that this a > good idea. Especially as we are now also sort-of-supporting WIndows, where > people can't just "apt-get install ladspa-sdk" to get it to compile > properly. > > Cheers, > > Marcus > > > _______________________________________________ > fluid-dev mailing list > fluid-dev@nongnu.org > https://lists.nongnu.org/mailman/listinfo/fluid-dev > _______________________________________________ fluid-dev mailing list fluid-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/fluid-dev
