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

Fons Adriaensen fons.adriaensen at skynet.be
Fri Mar 5 01:02:10 UTC 2004


On Thu, Mar 04, 2004 at 10:02:58PM +0100, Tom Szilagyi wrote:

> As an engineer a chill comes over my back if i think about the
> possibility of breaking something that works now.

As a system engineer a chill comes over my back if I think about the
necessity of having to take into account a mix of ad hoc methods
and solutions. A second chill follows when contemplating the fact that
a bad choice will be carried into the future and haunt us forever.

> Agreed. I basically believe that the ladSpa spec. is almost completely
> OK. However, one thing i would change is that i can't specify an
> arbitrary default for a control but only fixed ones eg. 0, 1, 100, 440.
> It would be nice to  have another hint where i could specify an
> arbitrary default value, probably in a very similar fashion as the
> port_range_hints[].LowerBound and port_range_hints[].UpperBound fields
> work.

The other thing that's missing is support for enumerated values such
as your presets, or for a simple n-position switch. If all the rest 
(continuous and integer values, limits, defaults... are supported
in the binary image, why not also these simple things ?

> 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 should 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 :)))

It's not my biggest trouble, but still one I prefer to avoid.
And if you mean what you say, why did you introduce that port name
string that includes all the preset names and that breaks every
host except Ardour ? Why shouldn't Ardour use the RDF if it wants
to display the preset names ?

In a more general setting: if you take the liberty to stretch the
port name concept way beyond it limits, then what should stop me from
introducing an extra hint bit or whatever it takes to put the same
information into the binary in a more portable way ?

> To me, the idea of a solid, stable core api (LADSPA) extended by
> an optionally provided/used metadata layer mainly concerned with
> gui appearance and default issues (RDF) is very pleasing.

It may be optional for things as preset names, but there are other
uses of enumerated choices where it is not really an option.

-- 
FA



More information about the Linux-audio-dev mailing list