Subject: RE: [linux-audio-dev] LADSPA extension proposal (quick action wanted)
From: Josh Green (jgreen_AT_users.sourceforge.net)
Date: Fri Dec 07 2001 - 14:18:12 EET
On Thu, 2001-12-06 at 16:00, Richard W.E. Furse wrote:
<cut>
>
> CONTROL PORTS SHOULD ACCEPT ARRAYS
>
> This is in the same family as a much more common request, "control ports
> should accept strings" (or doubles, events, MIDI, WFT etc). This requires a
> rather more complex API than LADSPA as the API has to handle memory
> management and more complex port descriptors. This requires a lot more work
> for the host programmer and is a potential barrier to plugin and host
> programmer. More in "going beyond LADSPA" below...
>
It seems like waveforms (for an envelope for instance) would be a really
useful control type though. But I can also see that this list of "nice"
data types could get quite large. I believe that LADSPA could be
designed, though, to put most of the burden of more data types on the
host rather than the plugin programmer. This would seem to me to be less
of a problem. Besides, if someone doesn't want to be confused by the
addition of more data types (I don't think it wouldn't be that bad
though) they could just use LADSPA 1.0. My opinion is that LADSPA is too
simple currently (to the point of crippling the options of what we can
do with it) and that some well thought out features are in order.
<cut>
>
> CHANGING CONTROL PARAMETERS DURING PROCESSING
>
> Hmm, this does sound like my style of specification English (and the "[at]"
> isn't appropriate IMHO!). I don't think it's unambiguous, although perhaps a
> little convoluted - the plugin is guaranteed that it can take sin(*ctrl) at
> the start of run() and cos(*ctrl) further on and get consistent results.
>
> It's important for a number of the reasons that the user and plugin know
> that the control value will stay fixed for the duration of the run() call.
> Some that spring to mind: (A) What happens when LADSPA runs on future
> hardware with small word sizes and larger floats? (B) Even if the float
> access is atomic, what happens when the host changes two interrelated
> control ports separately so inconsistent values are read by the plugin? (C)
> What happens if the C/C++ optimiser thinks it's more efficient to read twice
> from the control port? And it's pretty easy for the host to deal with the
> problem on its side.
>
<cut>
Why not add the ability for the plugin to specify if a control port can
be changed during processing? (#define LADSPA_HINT_CAN_UPDATE 0x40 ?)
Perhaps it doesn't make sense to have it a hint though, since these can
be ignored by the host.
Maybe the ability for a plugin to query the control state (constant or
modifiable) of a port would help it optimize itself, and/or add the
ability to LADSPA for checking if the value of a control port has
changed. A "port changed" query mechanism would also solve the cases of
more complex data types (such as arrays) if they ever get added.
I also remember disliking the fact that you don't know what the values
of control ports are until you are in the run function. At least for
constant control ports it would be nice to know what the values are in
the "activate" function. IIRC this was mentioned as the cause for
multiple versions of some plugins (delay_0.01s, delay_0.1s, delay_1s,
etc) because allocating resources inside the run function would render
it "non-realtime".
>
> --Richard
>
--
Josh Green
Smurf Sound Font Editor (http://smurf.sourceforge.net)
This archive was generated by hypermail 2b28 : Fri Dec 07 2001 - 14:14:11 EET