[linux-audio-dev] TAP-plugins reverb presets (fwd)

[Tim Goetze]

[Fons Adriaensen]
>On Fri, Mar 05, 2004 at 09:56:01PM +0100, Tom Szilagyi wrote:
>
>> I think the "dead end" has just been reached...
>
>Yes. Steve has made his position very clear: he opposes any change
>to ladspa.h. Much as I respect Steve for all his contributions to
>Linux Audio, I think this is misguided and  I do not share his
>opinion on what is 'meta' and what is not (and I sort of enjoyed
>Tim's posting an this subject).

thanks. i haven't given up on Steve yet. i admit he's stubborn, but
that simply behooves a good brit. he's also a bright mind, so he'll
realize sooner or later when he's supporting the wrong ideas.

unfortunately, his support for the ladspa 1.1 default value hack back
in the day has shown that 'sooner or later' sometimes means 'after the
milk has been spilled'.

maybe he's still shocked by the damage done to ladspa then, and his
consequence is to keep ladspa from changing at all now. i do not know.

(my apologies offered, Steve, for this rude, amateur public attempt at
understanding your motives.)

[good points about the other proposals elided]
>3. Then there is Tim's proposal, which allows for arbitary 'scale
>points' and which I think is clean and elegant, but that has the
>disadvantage of being much more invasive, as it introduces new
>fields and structs.  And that IMHO means that its chances of being
>accepted as a de facto standard are impaired - there will inevitably
>be some commotion before this happens, and Tim's idea, even if it
>is in fact straightforward and logical, offers much more lines of
>attack to those that would resist any change. And that is not
>because there is any real problem with it, but only because it is
>a lot more ambitious than what I dared to propose.

thank you for the favourable review.

i would prefer the term 'expansive' instead of 'invasive' for the
patch: it doesn't change a thing about ladspa as it is now. you can
patch all or only some of your local copies of ladspa.h, issue a
'make' for the projects affected, be they host or plugin, without
experiencing any problem at all.

i've also tried to show that there is no mutual exclusion between
the patch and RDF; in fact it remains to be shown that there even is
friction between the two. on the contrary, they'll mix well.

>To my own surprise, I find myself talking politics. This is starting
>to look like the US presidential campaign, so I'd better stop.

let's thank god this is not even half as grave as the US choice of
president. :)

to expand on the political aspect on this: since we'll never agree on
what goes into it at what does not, by far the most democratic option
is to let everyone have their *positive* will.

this is what the patch does: it realizes all concepts wished for so
far by all the plugin and host authors present on this list.

people who have gone over the patch will agree that it does so without
bloating ladspa.h, or if you prefer hard numbers:

-rw-r--r--    1 lad      lad         27447 Mar  5 15:21 ladspa.h.orig
-rw-r--r--    2 lad      lad         31478 Mar  6 01:09 ladspa.h

the patch even removes the need for the default value hack in ladspa.h
in the long run.

let's also not forget the most invasive change the patch introduces is
the TRIGGER and/or MOMENTARY hint bit; this is the only thing that
*can* cause problems between a 2.0 plugin and a 1.1 host, and it is
being agreed upon (in essence, not in implementation) by everybody so
far.

-

once again, my apologies offered for a long-winded post. i would like
to conclude it with another political statement:

live and let live.

be glad your wishes can be realized, and don't dispute the right of
others to see theirs realized as well.

vriendelijk,

tim