4 Mar
2004
4 Mar
'04
2:47 p.m.
On Thu, Mar 04, 2004 at 04:48:09PM +0000, Steve Harris wrote:
Didn't know that.
Well, you don't expect the host to compile and link the source code (this
should be perfectly possible of course). If it gets the code in a compiled
form that can (almost) be directly executed, why not do the same for the
all the data it needs ?
And if a second (text) file is used, I'd much prefer something simpler than
XML. A good candidate could be OSC for example. Any command language can be
used for configuration as well.
--
Fons
On Thu, Mar 04, 2004 at 04:59:31 +0100, Alfons
Adriaensen wrote:
That doesn't make it less bloated :-)
I had a look at the TAP RDF file, and compared
the useful contents to the
file lenght. The ratio of these two puts RDF in the 'bloated' category.
And it's not easy to read or write at all.
It is not a problem if you use a library. What is more
disturbing is that there are now at least 3 ways to obtain info
on a LADSPA plugin port:
1. form the port descriptors,
2. by interpreting the name of the port (e.g. 'latency'),
That was partly my fault, and its not good, but the latency value can
depend on input port values, so I couldn't think of an alternative.
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).
3. from the RDF file, which may repeat or
contradict some of 1.
Mostly default values. RDF defaults for LADSPA predate ladspa.h default
hints, which are a hack. To me this is
a mess. It should be perfectly possible to extend the port
descriptors in such a way that things like preset names, scale ticks,
units etc. are available from there.
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?