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

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: This ladspa-rdf stuff works? Was: Re: [linux-audio-dev] TAP-plugins reverb presets
From: Steve Harris (S.W.Harris_AT_ecs.soton.ac.uk)
Date: Sat Mar 06 2004 - 14:25:54 EET


On Sat, Mar 06, 2004 at 02:28:20 +0100, Tim Goetze wrote:
> >> * 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.

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

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

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

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

- Steve


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Sat Mar 06 2004 - 14:24:58 EET