4 Mar
2004
4 Mar
'04
9:12 p.m.
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