Subject: Re: [linux-audio-dev] LADSPA v1.1 Alternative Proposal
From: Conrad Parker (conrad_AT_vergenet.net)
Date: Thu May 30 2002 - 06:46:03 EEST
On Wed, May 29, 2002 at 11:51:56PM +0100, Richard W.E. Furse wrote:
> > -----Original Message-----
> > From: linux-audio-dev-admin_AT_music.columbia.edu
> > [mailto:linux-audio-dev-admin_AT_music.columbia.edu]On Behalf Of Tim Goetze
> > Sent: 29 May 2002 22:32
> [...]
> > >totally agree -- Tim's solution doesn't break binary compatability,
> >
> > richard pointed out that it'd actually break binary compatibility with
> > hosts that call connect_port at every processing cycle.
> >
> > however, until these hosts are fixed, it only means 'always default'
> > rather than 'always segfault' for them so i'm still for it.
> [...]
>
> To flesh this out, some problems I can think of with this approach are as
> below (mostly following from the first):
I'll deal with each in turn, but preface this by clarifying that we are
only talking about control ports, not audio ports, because:
* conceptually, we're only talking about default parameters;
default audio input would be a somewhat stranger concept.
* practically, connect_port() doesn't have a SampleCount arg
so it could not consider blocks of audio.
You made this point in 4. and 5. below too, I don't think anyone was asking
for default audio input.
>
> 1. Writing to inputs is conceptually ugly.
sure. but initialising inputs to a sensible default at creation isn't
nearly as bad -- and only the plugin knows what is sensible. The scheme
you suggest with a multitude of hints either offloads much of that
decision onto the host, which simply cannot know which values are useful,
or unnecessarily limits default values to {0.0, 1.0, 100.0, 440.0}.
It's writing to inputs at run() which would be truly ugly ;)
> 2. The find a default a GUI has to do the following: [a] load the library,
> [b] instantiate the plugin, [c] write a value to a memory location, [d] call
> connect_port(), [e] compare old and new values, [f] if they're the same,
> repeat [c] to [e] with a different value in case the written value happened
> to be the default, [g] destroy the plugin. This can be simplified by
> addition of a default flag, but even so it's ugly.
no; a host need only do [a] [b] and [d].
I'd argue that a host only ever gets down to the nitty gritty of considering
actual data values when it's getting ready to run -- ie. the user has already
indicated they want to be using this plugin, the host has a sample rate, it
just wants to go that extra step and set up the parameters before calling
run().
By the time a host needs defaults, it's already done [a] [b] and [d].
> 3. A plugin has to be loaded and instantiated to find a default value - it
> is no longer possible to deal with the plugin in the abstract using just
> descriptor data (which is easily marshalled).
yes, it would not be possible to deal in the abstract with concepts like:
* default gain = 0.7
* default window_length = 0.25 * sample rate
(these concepts look pretty concrete to me!).
It would still be possible to deal in the abstract with concepts like:
* the gain control is a logarithmic input
* the window_length is an integer input with these bounds
I think the point of "dealing in the abstract" is to consider the scope and
use of a parameter, eg. in order to decide what kind of slider to display or
to decide whether a host can make use of a plugin at all. But by the time
you're considering default values, your dealings are getting concrete.
> 4. The semantics are untidy with audio ratio ports and outputs. Output
> defaults are admittedly of limited usefulness (but of some - consider a host
> that's going to filter the output or flash a light when a toggle changes - a
> default is a useful initial value). Audio rate defaults ARE useful - however
> at the connect_port() stage the plugin can write only to the first point of
> the buffer. Only the host knows how long the buffer is and will have to copy
> the value through the buffer so it cannot just connect the port and forget
> about it.
yes, default audio input is stranger and not part of this proposal.
> 5. connect_port() used with read-only shared memory or memory-mapped
> soundfiles will segfault (I'm mostly using using IEEE float soundfiles at
> the moment, so the latter is a real requirement).
yes, another reason not to handle default audio input.
> 6. Hosts can no longer usefully call connect_port() each frame - they will
> always lose their intended input data on defaulting ports. These hosts will
> always have to copy data into place, in which case it's more efficient just
> to call connect_port() once only at initialisation. This is a nuisance for
> hosts using event or frame packets rather than fixed data areas (e.g.
> Glame?).
as others suggested, perhaps hosts built in this way are broken anyway.
in any case, I'd think it's *less* efficient to call connect_port() each
frame than to copy a single float of data to a known location each frame.
> Creative thinking though...
>
> My preference is the extra 4bits of hint. I'm happy to get rid of the high
> and low options if they're too confusing or just leave defaults as the job
> of whatever GUI wrapper layer is used - I'd prefer to keep LADSPA simple.
heh, I'd prefer to keep LADSPA simple by not changing it at all, only its
required usage :)
so, I hope I've clarified the case for having default control inputs
returned from connect_port(), and not requiring any changes in port hints
etc.
generally, I think the approach of being dynamic, not static is quite
powerful; we've used similar concepts for the plugin APIs in MPEG Maaate
and sweep (which have separate suggest() functions rather than static
defaults) and it gives more power to the plugin, so that the plugin can
reliably present itself as usefully as possible to the user without the
host having to second-guess the default values.
cheers,
Conrad.
This archive was generated by hypermail 2b28 : Thu May 30 2002 - 06:40:22 EEST