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: [linux-audio-dev] TAP-plugins reverb presets
From: Tim Goetze (tim_AT_quitte.de)
Date: Fri Mar 05 2004 - 01:12:23 EET


[Tom Szilagyi]
>[Tim Goetze]
>> so at the end of the version 1 descriptor struct we can add fields
>> galore, starting, obviously, with a version field. of course plugins
>> must not rely on version 2 features if they are intended to work with
>> pre-version 2 hosts.
>
>This last sentence is particularly true, and this is exactly why it
>would be very painful to actually do it. As a plugin author/maintainer,
>you don't want to update your core code every now and then when someone
>else discovers she needs just one more possibility to add. And you don't
>want to see your plugins rendered useless in a number of hosts, just
>because their authors didn't catch up with implementing the latest and
>greatest achievements of ladSpa possibilities. If a host doesn't make
>use of metadata, that should be OK -- gui may be crappy, but after all,
>the plugin should *work*. Any plugin, in any host. That's the point.

i agree to your reasoning and your concerns seem valid to me. yet i do
not think this is as much of an issue as it may seem now: the core
functionality is in ladspa 1.1, and it is proven usable.

what we are missing are more refined ways of telling the host about
the plugin: latency, arbitrary default values, value units. adding
these will not in any way be harmful to the operation in hosts not
aware of the extra information, but it will benefit those in the know
to treat the plugin as intended.

i can't come up with a sensible extension to the ladspa standard that
would break this rule of 'benefit where possible, no harm else' right
now (though i'm sure there will be examples, which will then probably
receive due consideration by the lad crew).

>Yes, particular plugins like my reverb or other fairly complex ones
>could use some extra possibilities, but that can be satisfied by an
>external and *optional* set of metadata, and i don't see why RDF won't
>be good for this purpose. The metadata sBhould be (and currently, it
>*is*) completely optional both to provide and to use. (oh, RDF is
>bloated... yes, it is. May this be the biggest trouble in our lives :)))

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 have next to no opinion on what the metadata storage format should
be. RDF is fine (although i admit the term 'human readable' strikes a
slightly different note in me :) if everyone agrees on it, and steve
has already put a lot of work into it.

vriendelijk,

tim


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

This archive was generated by hypermail 2b28 : Fri Mar 05 2004 - 01:16:59 EET