Subject: Re: [linux-audio-dev] TAP-plugins reverb presets
From: Tom Szilagyi (st444_AT_hszk.bme.hu)
Date: Thu Mar 04 2004 - 23:02:58 EET
Hi all,
It was very interesting to read all your opinions.
Here are mine. :)
[Steve Harris]
> 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]
> 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.
[Tim Goetze]
> so at the end of the version 1 descriptor struct we can add fields
> galore, starting, obviously, with a version field. of course plugins
> must not rely on version 2 features if they are intended to work with
> pre-version 2 hosts.
This last sentence is particularly true, and this is exactly why it
would be very painful to actually do it. As a plugin author/maintainer,
you don't want to update your core code every now and then when someone
else discovers she needs just one more possibility to add. And you don't
want to see your plugins rendered useless in a number of hosts, just
because their authors didn't catch up with implementing the latest and
greatest achievements of ladSpa possibilities. If a host doesn't make
use of metadata, that should be OK -- gui may be crappy, but after all,
the plugin should *work*. Any plugin, in any host. That's the point.
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 :)))
[Tim Goetze]
> extending the port range with an arbitrary default value is then
> possible by simply extending the range structure in similar fashion
> (or adding a LADSPA_Data ** default_values member to the descriptor
> struct, or whatever mechanism gets the votes).
Yes, i support that particular possibility. What i wouldn't like to see
is the emerge of multiple versions with multiple possibilities, varying
host support of these features etc (as i've stated my opinion above).
[Matthias Nagorni]
> The combination of the very simple LADSPA api with something as
> complicated as RDF seems a bit odd to me. I would wish if there was a
> simpler solution.
We agree it's not a simple solution. But it's a solution anyway :)
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.
Tom
This archive was generated by hypermail 2b28 : Thu Mar 04 2004 - 23:08:06 EET