5 Mar
2004
5 Mar
'04
5:25 a.m.
On Fri, Mar 05, 2004 at 02:02:10 +0100, Fons Adriaensen wrote:
Because they weren't thought of at design time. There is allready
enumerated value support in RDF. Very simple hosts do not need it.
Thats what Taybin was working on last night.
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
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 ? 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.