Subject: Re: [linux-audio-dev] LADSPA v1.1 Alternative Proposal
From: Conrad Parker (conrad_AT_vergenet.net)
Date: Wed May 29 2002 - 07:17:44 EEST
regarding the provision of default values in LADSPA, I totally support
Tim's suggestion -- in fact, I reckon it is brilliant for reasons I'll
outline below :)
On Tue, May 28, 2002 at 04:25:21PM +0200, Tim Goetze wrote:
> Steve Harris wrote:
>
> >On Mon, May 27, 2002 at 02:21:04 +0200, Tim Goetze wrote:
> >> so what do you think about the actual proposal? (*DataLocation =
> >> default in connect_port)
> >
> >I don't think it gains anything over Richards original suggestion, does
> >it? The problem is that it moves the definition of the defualt values away
> >from the definition of the port's data.
>
> agree. however i reckon it won't hurt too badly to have default values
> no sooner than when the plugin is instantiated.
I think it's even more powerful this way because it lets a plugin calculate
defaults programmatically, taking into account the instantiated sample
rate and the state of the plugin.
if we restricted ourselves to keeping the definition of default values
near the definition of the port's data, we would restrict ourselves to
static default mechanisms, such as simple default values or kludgy
default boundaries.
by making the defaults an outcome of connect_port() instead, we get a
dynamic mechanism for free. Default frequencies can be related to the
sample rate, etc.
Going further (but still without breaking binary compatibility), we
see that we are already allowed to call connect_port() multiple times,
even between calls to run(); from ladspa.h:
connect_port() may be called more than once for a plugin instance
to allow the host to change the buffers that the plugin is
reading or writing. These calls may be made before or after
activate() or deactivate() calls.
so, a very smart plugin could profile the data it is being fed via run()
and then suggest a very relevant default value for a parameter on a
subsequent call to connect_port().
So, now, default values can be related to the plugin's state and the
kind of data being processed (eg. a suggested compression ratio for the
kind of data that has been processed so far).
All this requires is that a plugin suggest default values in the way
Tim proposed: by setting *DataLocation before returning from
connect_port().
It would still be perfectly valid for a host to ignore this, and it would
still be perfectly valid for a plugin to not modify *DataLocation, so
existing hosts and plugins should not be affected.
>
> the LADSPA_HINT_DEFAULT_* solution looks very awkward to me, and
> despite all the code it involves it isn't even capable of expressing
> any value from the valid range.
>
> i think it would even be better to break binary compatibility now than
> force ourselves to support a kludge like this (sorry, richard) in
> future versions of the API.
>
> it is better to admit that we cannot have a perfect solution without
> breaking binary compatibility, and thus should at least go for the
> simpler one, i think.
totally agree -- Tim's solution doesn't break binary compatability,
doesn't introduce any new symbols or macros and doesn't consume any bits
out of the port hints; plus, it allows plugins to set defaults using any
criteria they like.
all it requires is additional (but backwards-compatible) behaviour for
those plugins and hosts that care about default values, and that this
behaviour be documented in ladspa.h.
a suggested patch to ladspa.h, touching comments only, is attached :)
Conrad.
This archive was generated by hypermail 2b28 : Wed May 29 2002 - 07:10:50 EEST