4 Mar
2004
4 Mar
'04
7:30 p.m.
On Thu, Mar 04, 2004 at 10:02:58 +0100, Tom Szilagyi wrote:
[Steve Harris]
I'd agree that changing it now is wrong, but infact its very hard for
hosts to support dynamic latency changes (the semantics are undefined for
one thing), and there aren't that many plugins that it affects. With the
benfit of heighsight, I would do latency values with RDF.
I'm begining to think that it should have been
a fixed value (in RDF of
course ;) and plugins with varying latnecy shouldn't be corrected for).
Shouldn't be functionality have a priority over simplicity or ease of
use? As an engineer a chill comes over my back if i think about the
possibility of breaking something that works now (eg. changing latency
when the user adjusts some setting) in favour of being able to achieve
a simpler plugin description. (And in fact, my pitch shifter actually
makes use of this possibility; it would be impossible to maintain
sample-precise output position without this.) [Steve Harris]
Yes, thats what we wanted to do when it become obvious we needed default
values, but its not possible to do that without changing the sizeof()
the port struct which will break binary compatibility. It didnt seem that
that was acceptable at that point. There are other solutions, but they are
all ugly.
There is an RDF mechanism for defaults (of course, just use ladspa:Default
instead of ladspa:Preset, same parent class), but I dont think many hosts
look for them. Chicken and egg.
It would be, but its hard to keep binary
compatibility and wouldnt it be
better to just have one extensible metadata format that you can use for
ports descriptions, scales, defaults, and presets?
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. But i do think fancy things such as these damned
reverb preset names
should be in a separate metafile, since not every host wants to use them
and i feel this is a cleaner design than embedding everything in the
core source file.
Truely.
You can keep adding stuff to the LADSPA structs till the cows come home,
but its hard work for everyone to support and difficult to maintain binary
compatibility. OTOH adding things to an RDF schema is very easy,
back- and forward-compatibility can be guaranteed, and most of the helper
functions in liblrdf are < 30 lines.
Its not the universal panacea, as people have pointed out RDF files are
pretty bloaty (though in memory they are small), and RDF parsers are
hellish to write, but it is very useful.
- Steve