Re: [fluid-dev] Bundling ladspa.h

[Tom M.]

> 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 <address@hidden>:
> 2017-11-13 11:33 GMT+01:00 Kjetil Matheussen <address@hidden>:
>>
>> 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
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/fluid-dev
>