5 Mar
2004
5 Mar
'04
8 p.m.
On Fri, Mar 05, 2004 at 11:21:32 +0100, Tim Goetze wrote:
like others, i'm not quite sure discussing this
any further is going
to be particularly fruitful, but here goes anyway.
Agreed. I think we should all sleep on it for a few days at least.
i would like to carry your definition to the extreme
in a fiendish and
unfair manner, as is my custom (and please let me prefix this with an
expression of my utter regret of being so rude, and with an assertion
of my deepest respect for all your fine efforts in the field so far):
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.
all information vitally needed for machine *and* man
to treat and use
the plugin as intended, without querying other sources than the plugin
itself, is *not* 'meta'. it is 'direct' or 'inherent' knowledge.
I dont really want to get into a discussion on machine semantics (I charge
for that ;), but metadata has a definte meaning (data about data), even
though the meta- prefix doesnt.
* 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.
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.
yet to top it off, i would like to question your point
of 'keeping
this out of ladspa is making coding simpler'.
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.
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.
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.
- Steve