[linux-audio-dev] TAP-plugins reverb presets

Tim Goetze tim at quitte.de
Thu Mar 4 20:10:30 EST 2004

[Steve Harris]
>> yes, may it :) and agreed again. concerning presets, help text, value
>> scales, value range coloring etc etc, i'm all for storage external to
>> the plugin. in contrast, information of immediate importance: latency,
>> refined defaults and unit identifiers ("dB", "ms", ...) should be
>> internal imo.
>I do not think these things are critical to the functioning of all hosts
>or plugins, and so should be external.
>Units are a good case in point. You could just have a char *
>representation, or you could (hypothetically) have some structured
>repesentation say that ms was a Time unit with a long name of
>"milliseconds" and it has ratio of 0.001 with the SI base unit, which is
>the second, which has...
>If you code that in the spec you either need a complex data structure (and
>so a library to read it ideally) or you encode the knowledge in every
>host, whereas is you encode it in RDF, you just express the units once in
>the schema and all hosts can access it, plus if a plugin needs to declare
>new units (or even a new class of units), it can, and they will be
>understood by all hosts, even if they've never seen that unit before.
>Hosts that just want to render the units after slider can just ask "whats
>the label for port 3's units", whereas hosts that want to do tempo -> time
>mapping for eg. can ask what they are and what thier relation to seconds

i agree that all this information is useful to have, but i would not
like to push the use of RDF onto hosts intended to be simple.

in fact i think internal unit IDs prove very well how internal and
external can work together: a host that doesn't not want to use RDF
can still derive some very useful clues, and be it only what to draw
next to a value scale. only a full-blown host will want to query more
verbose sources about the nature of the unit and port. but let's not
get stuck on this detail.


i have some doubts that the dividing line between internal and
external should be 'what is necessary to run the plugin?'. we wouldn't
even have the default value mechanism we have now if that was the

a better divider is probably, as has already been hinted, 'meta-data
is external'. presets surely are meta. what kind of scale/grid to draw
next to a slider also is. inherent information is not: latency is not
meta. units are not meta. default values are not meta because they can
decide between stable and unstable, and give the user detailed clues
about the intention of the plugin.


in general, i'd also like to note:

dancing forever around the S in ladspa, yelling 'heretic' at any
extension proposal, is only going to make us the fools of the
universe. we only have this standard and things are evolving, and so
it also must.



More information about the linux-audio-dev mailing list