Re: [linux-audio-dev] TAP-plugins reverb presets

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] TAP-plugins reverb presets
From: Steve Harris (S.W.Harris_AT_ecs.soton.ac.uk)
Date: Fri Mar 05 2004 - 01:24:57 EET


On Thu, Mar 04, 2004 at 10:02:58 +0100, Tom Szilagyi wrote:
> [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.)

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.

> [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.

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.
 
> 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


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Fri Mar 05 2004 - 01:23:33 EET