Subject: Re: [linux-audio-dev] LADSPA v1.1 Alternative Proposal
From: Conrad Parker (conrad_AT_vergenet.net)
Date: Fri May 31 2002 - 10:25:45 EEST
On Thu, May 30, 2002 at 06:30:35PM +0100, Steve Harris wrote:
> On Thu, May 30, 2002 at 09:41:25 -0400, Paul Davis wrote:
> > >I would say that persets are metadata, and so they should be seperate
> > >from the API.
> >
> > do you agree that defaults are really a preset?
>
> Yes, but I was being pragmatic. I think that defaults are more important
> than a standardised preset format.
yep, I agree -- we *need* a mechanism for defaults so that users can load
up a plugin and work with useful settings from the start. Without that,
LADSPA is a harcore-audio-hackers-only tool; with it, users could learn
about the plugins by experimenting with them (and hence, become hardcore
audio hackers, so that they too may contribute to LAD's world domination :).
general presets, on the other hand, are more of a *want* item -- they're
cool, but can wait past LADSPA 1.1. [The lower half of this message
discusses this ...]
> I also thought that it would be easier
> to get people to agree on a defaults system than a presets system.
>
> This doesn't appear to be true ;)
getting there -- a few people still need to make up their minds ;)
> > since you've already agreed that we need defaults, and since i find it
> > hard to argue with the idea that defaults are presets, i personally
> > find the conclusion that we actually need an API for presets fairly
> > compelling.
>
> API, no. Spec, yes.
>
> An RDF (for preference) or XML file + filesystem convention should do the
> job. We've been there before though.
>
> Maybe we should have a presets server, or write it on punch cards and read
> them with a scanner. ;)
Hehe.
I think we're confusing two kinds of presets, and hence some people want
presets in the plugins, and some want them separate (RDF, XML, punch
cards ...). [I haven't seen this distinction covered before, apologies
if it has been.]
First up there are presets without which the plugin is fairly useless to a
novice, and which would be equally useful to everyone just to get started.
These include defaults and, for plugins with more than one mode of
behaviour, a canonical example of each mode. These are known by the plugin
author at the time of writing the plugin, and for all intents and purposes
are part of the plugin. Some concrete examples taken from Steve's LADSPA
Plugin Docs (http://plugin.org.uk/ladspa-swh/docs/ladspa-swh.html):
* The description of Juhana's GVerb contains the comments:
Roomsize (m) ... Values of around 30 sound good
Reverb time (s) ... 7 is a good place to start.
The plugin should simply start at a good place ...
* The description of the Crossover distortion is:
This is a simulation of the distortion that happens in class
B and AB power amps when the signal crosses 0.
For class B simulations the smooth value should be set to
about 0.3 +/- 0.2 and for AB it should be set to near 1.0.
These two modes of simulation would be equally useful starting
points, as suggested by the plugin's author.
Let's call these "author presets".
Secondly, there are presets which a user discovers through experiment and
wants to save for later, or which users trade with each other, or which
the plugin maintainer or distributor thinks are simply cooool. These evolve
over time. Let's call these "user presets".
The nature of author presets is that they should always exist when the
plugin exists, and they will not change or develop over time other than
when the plugin does. I'd suggest these should be provided by the plugin,
and available through the LADSPA API.
User presets, on the other hand, must be user definable, edittable,
shareable, etc. and for these, RDF/XML/punch cards make sense.
If we keep author presets within the plugin, then we can know they will
always be available and correct, even if the user blows away or messes up
their user presets, or if a new version of the plugin alters its parameter
usage and gets out of sync with its previous presets.
If we keep user presets separate from the plugin, users can modify them
and share them, and never risk harming the plugin.
Hence, finally getting back to Paul's suggestion -- ie. taking a step back
and looking at the bigger question regarding defaults -- I think it makes
sense to:
* handle author presets (at least a single set of defaults) through
the LADSPA API.
* handle user presets through a separate means such as RDF/XML
Conrad.
This archive was generated by hypermail 2b28 : Fri May 31 2002 - 10:17:26 EEST