Subject: RE: [linux-audio-dev] LADSPA v1.1 Alternative Proposal
From: Tim Goetze (tim_AT_quitte.de)
Date: Thu May 30 2002 - 13:52:16 EEST
i wrote this before fetching mail, so it happens to be mostly a
reiteration of conrad's points. skip to the last paragraph if you
find this mail lengthy, boring, or both.
Richard W.E. Furse wrote:
>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.
agree. however expressing the same fact as 'initializing a port
belonging to the plugin' is as appropriate, and does sound rather
sane i think.
>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.
why repeat [c-e] if the host can write a value outside the valid
range? and why would you care about the default value if you are
not going to run the plugin [g]?
and if a host really needs the default value a priori and so badly,
would you as its programmer like to accept the fact that all you can
get is an educated guess instead of the value truly intended by the
plugin programmer?
if a host is designed to use the mechanism the right way, it doesn't
need to care about the default at all. it only needs to fetch the
current value whenever needed, and set the initial value, if one is
provided, after rather than before connect_port().
>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).
if you agree on my views on 2. you'll also agree this question becomes
academic. we needed default values to *run* the plugins like they were
intended to, didn't we?
>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.
we don't have control value arrays in LADSPA, only single values if
i'm not totally mistaken. at least i remember proposing control arrays
a while ago, without general consensus. :)
if we must write defaults to arrays, then of course the one value
written becomes the default, and the host responsible of initializing
the rest of the array if needed -- would you want the plugin to be
able to say something like 'the default is i toggle the switch at
every sample'? ;)
>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).
if you're talking about audio ports: they already have a default
(silence = 0f) if i am right in my interpretation of LADSPA 1.1 so
far. thus a plugin need not and, to enable your scenario, must not
write this value.
if we should choose to support CONTROL | AUDIO, the same reasoning
applies.
and if you really do run control ports on mmap()ed data the good news
is your host probably gains in efficiency *not* doing the indirect
call of connect_port() at every cycle.
>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?).
since we only need buffered values for single-value control ports, it
is not a big deal to fix those hosts.
and, coming back to aesthetics, i think that the current control port
value is really a property of the plugin, and expressing this in a host's
data structures cannot be a bad thing because it means expressing
reality.
>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.
yes, we all do. please let me excur to explain why i think a GUI
control is simpler to do, too: fetch the current value when the
control is initialized and declare it the default. if it is the
plugin's default, fine. if it is restored from a saved state, this
state becomes the default for the current session. actually rather
elegant i think -- as a user, if i get to choose, i actually prefer
reverting to the last known good state than to the plugin default.
i guess it is safe to say that '*DataLocation = default' is simple:
it is simple to implement in a plugin for sure. it is reasonable for
hosts not to care about the default value at all. it gets the
efficiency bonus for being capable of expressing any value from the
valid range while saving many lines in <ladspa.h>. it makes, as conrad
parker showed, the dynamic creation of sane values possible if you
stretch the meaning of 'to connect' a bit, and above all: it is
easy to explain and understand.
i vote for collecting more votes.
cheers,
tim
This archive was generated by hypermail 2b28 : Thu May 30 2002 - 13:45:07 EEST