This ladspa-rdf stuff works? Was: Re: [linux-audio-dev] TAP-plugins reverb presets

[Tim Goetze]

prologue: this mail is not intended to be a smooth read. if you have
any kids around, tell them to play somewhere else please. i am an
impatient, flawed kind of character quick to give in to a sudden
temper.

[Steve Harris]
>> i'm not sure a studio professional will agree with your estimation of
>> the vitality of these information bits, in part or in toto.
>
>True, but I dont think many studios would work with applyplugin or
>(command line) ecasound either. Nor would they be happy with an
>alphabetically sorted list of plugins, but sofar nones claimed that
>categorisation should go in the .so file.

to me, this sounds like: we're engineers, sc*ew the rest. it also has
a faint taste of that famous '640k will always do' quote.

to repeat: nobody is disputing the usefulness of RDF for what you
intend it to do for us, on the contrary. and i may remind you that
the particular convenience it offers is mostly for people who can't be
bothered with the technical details.

>> * ladspa isn't that simple anymore, take a step back and look at the
>> default value mechanism in place now if in doubt. i would think it's
>> not sensible to protect the virginity of a princess already raped.
>> compared to that, the patch is downright fool-proof. add to this that
>> in the long run, the patch will even rub out this sore spot.
>
>I agree that defaults should have been LADSPA_Datas recorded in the .so
>file (for symmetry with min and max), but we allready dismissed recording
>defaults in a vector in the main struct as being too ugly when we specced
>out defaults originally (if you cast your mind back). We allready have a
>vector of structs thats supposed to represent the properties of ports...
>except defaults. Not good.

the 'ugly' argument is simply misplaced.

1) this is a pure engineering effort, designed to interface software
with software. 'beautiful' or 'ugly' is not what this is about, as it
relies on a highly subjective mode of judgement. 'functional or not'
is a much better choice of distinction, and i'm more than willing to
discuss the merits of the patch in this regard.

2) expanding an API to do things it didn't do before while being
compatible is always 'ugly', to use your choice of terminology. as
witness i call the default hints in ladspa, and proceed to

3) removing the default value hack, and be it with a vector of values,
will make ladspa less 'ugly'.

4) even ladspa 1.0 was 'ugly'. there are much 'nicer' designs of APIs
around, if you ask me.

5) has it occurred to you that many people object to RDF as being
'ugly'?

>I would be in favour of some approach the fixed that (deprecating default
>hints), but theres nothing obviously good.

which is why we have to bite the bullet.

>One approach is to reflect the current port structures into the main
>struct (requiring that 1.2 plugins fill in both values) and deprecate the
>port structure in a future, non back-compatible .0 release. Thats not
>good either though.

agreed.

>> * the 'simple' in ladspa also means: all you need, in a compact frame.
>> a frame that RDF bursts, and one that the patch keeps intact. (and we
>> do agree we need more than ladspa 1.1 offers.)
>
>Yeah, but the RDF stuff is optional - you can write plugins and hosts that
>will work well without it, so it doesnt bump up the learning curve.
>You can look at it when you're writing plugins of the level of complexity
>that need it, at which point is pretty in significant.

i'm sorry for having to meet your stubbornness with repetition myself:

THE EXTENDED FEATURES IN THE PATCH ARE OPTIONAL AS MUCH AS IS RDF, SO
PLEASE REFRAIN FROM REPEATING THIS POINTLESS ARGUMENT IN THE FUTURE.

>>From the hosts p.o.v its very simple (just use the liblrdf convienienve
>functions if you dont want to wrangle RDF yourself), and someone could
>write a GUI app to generate RDF descriptions of plugins easily enough.

it has been shown in code that access to the extended features from
the host side is just as simple as is liblrdf (and one may want to
argue: even simpler because of a removed level of indirection).
further down your post, you admit to this yourself.

>> * from the very beginning, ladspa has included meta data (by your
>> strict definition of meta and data), and for good reasons. departing
>> from that now may look good from an academical point of view, but in
>> fact it's a rougher breakage than keeping with the spirit.
>
>True - except that the RDF stuff is independent, and the extensions we've
>been discussing also break the spirit of LADSPA 1.0.

what does really break the spirit: excluding what you call metadata or
including it, recalling that your interpretation of metadata doesn't
even fit the data included in ladspa 1.0?

>> i've just now compiled swh-plugins-0.4.3 against 2.0, without any
>> compilation issues or problems using the compiled plugins. no need
>> to change a single line of code.
>
>Sure the problem is the extra stuff in the spec and the schitzophenic port
>/ default vector situation. I do like the fact that you can just implent a
>plugin to the 1.1 spec and it will work (except defaults), which helps.

the port/default vector schizophrenia is something we'll have to live
with anyway. in this context, i would like to point out that port
names are a separate vector as well, and have been ever since ladspa
1.0, so it must be concluded we don't even introduce a new concept.

>> i'd also like to point out (as the test program posted with the first
>> patch shows) that querying the additional information from the plugin
>> isn't even nearly as hard as deriving default values is right now. add
>> to this that the use of the value->label enum is optional, and that
>> 2.0 makes it possible to specify default values directly: one must
>> conclude that writing plugins with 2.0 is even easier than it is with
>> ladspa 1.1.
>
>Easier for the host, but there are less of them. Just incase your in any
>doubt, I do think default belong in the .so, just not the other (non-hint)
>stuff.

that you have made more than clear by now. :)

amicalement,

tim