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

Steve Harris S.W.Harris at ecs.soton.ac.uk
Fri Mar 5 09:20:38 UTC 2004


On Fri, Mar 05, 2004 at 02:02:10 +0100, Fons Adriaensen wrote:
> > 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 ?

Because they weren't thought of at design time. There is allready
enumerated value support in RDF. Very simple hosts do not need it.
 
> > 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 ?

Thats what Taybin was working on last night.
 
> > 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.

IMNSHO that was not the best way to implement preset selection - just
storing the presets as RDF on disk and letting the hosts (that can / want
to) pick them up is a better idea.

You cant describe enumerations as a critical core feature, because we've
got along without them for 4 years. I'd agree that its not optimal, but I
also dont think they should bloat the port structure and break binary
compatiblity, or the plugin structure and mess up a perfectly good binary
format.

- Steve



More information about the Linux-audio-dev mailing list