RE: [linux-audio-dev] LADSPA v1.1 Alternative Proposal

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

Subject: RE: [linux-audio-dev] LADSPA v1.1 Alternative Proposal
From: Richard W.E. Furse (richard_AT_muse.demon.co.uk)
Date: Thu May 30 2002 - 01:51:56 EEST


> -----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):

1. Writing to inputs is conceptually 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.
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).
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.
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).
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?).

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.

To provide a public answer to objections to provision of a reference
getDefault() implementation, this would just be a short function in the SDK
that host writers could steal if they couldn't be bothered to handle the
different default flags values themselves.

Best wishes,

--Richard


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

This archive was generated by hypermail 2b28 : Thu May 30 2002 - 01:49:04 EEST