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

[Tim Goetze]

[Steve Harris]
>On Fri, Mar 05, 2004 at 11:21:32 +0100, Tim Goetze wrote:
>> what do we have in ladspa that is *not* 'meta'?
>>
>> * we have a plugin.
>> * the plugin has n ports.
>> * it also offers certain methods to carry out operations for us.
>
>Thats not feindish, or unfair, its almost correct :) Another thing thats
>arguably not metadata is the identifier. I think identifiers are not
>metadata, others disagree.
>
>I do think metadata that's needed by every plugins (ranges, defaults,
>the hints etc.) may as well be in the .so file (it meets LADSPAs needs but
>its not ideal).
>
>Like Torben said, if the base standard was more complex (e.g. LADSPA 2,
>GMPI, whatwever) it would be much easier to handle if /all/ the metadata
>was external.

your definition of meta data seems much to the point. however it also
seems we still are in disagreement, this time over the limits of the
'data' that is described by the 'meta'. but pursuing this distinction
any further is, as you point out so rightly, probably beyond the scope
of this thread.


>> * everything labeled 'meta' in the above thought experiment becomes
>>   'not meta', except for the presets.
>> * knowing that 0.5 = half a second is 'not meta'.
>> * knowing that 0 = sin, 1 = tri, 2 = saw is vital, thus 'not meta'.
>> * knowing that the plugin causes 64 frames delay is 'not meta'.
>
>These things are not vital. They might be useful sometimes, but you can
>operate the plugin without them being encoded in a machine readable form.
>I'm not sure thats relevent though.

i'm not sure a studio professional will agree with your estimation of
the vitality of these information bits, in part or in toto.


>The key issue (from my point of view) is wich is simpler - representing it
>in the .so file or in RDF. I think the answer for most things that need
>more than a HINT bit at this point is do it externally.

ok, the 'simple' argument. three things against that:

* 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.

* 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.)

* 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.


>> what do you think is simpler to do for somebody new to all this:
>>
>> * learning the API, or
>> * learning the API *and* RDF?
>
>Thats a good point, but everytime we add something to the core spec it has
>to be understood before you can write a plugin, whereas anything encoded
>in RDF is optional by definition.

as is the use of 2.0's extensions: optional, you can write your plugin
or host entirely disregarding them.

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.

afaics, RDF and the extensions mix well. if you would like to see
that, we can amend the patch stating that data about the plugin that
is queried from RDF sources overrides the corresponding ladspa
members. i even think this is very sensible, it's a very convenient
way to customize after all.

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.


>Given examples, writing RDF is certain no harder than writing C. It's
>difficult for me to judge how much easier, as I have worked with RDF quite
>a bit.

we'll all work with it a lot if everyone agrees on it for storing
metadata, and i do. :) i'm even looking forward to it fwiw.


>If you do want to discuss plugins from a knowledge mangement viewpoint
>I'm happy to, its something I've been thinking about, I plan to write a
>paper about it sometime, but its not directly relevant to this thread.

sure, it's good fun to discuss this. but i agree we should keep it out
of this discussion for the time being.

vriendelijk,

tim