Subject: Re: [linux-audio-dev] LADSPA extension proposal (quick action wanted)
From: Paul Davis (pbd_AT_Op.Net)
Date: Thu Dec 06 2001 - 17:50:32 EET
>> imagine, but its not clear how you would write the data to the control
>> port: it can't be done atomically, and you don't want the plugin
>> working with a partially overwritten data set. so, i can easily
>
>Yes, I see the problem now. The only solution I can see is that the host
>will have to hold the new array until the plugin has finished its
>run() function and then update.
>
>NB. this is potentially also an issue for single float parameters, in many
>situations you have to ensure that a parameter is safe before doing maths
>on it != 0.0 for example. I try to avoid changing the port itsself, but
>there is nothing that requires that IIRC.
OK, this is a good general point. However, for scalar values, the
problem is simply solved on the plugin side: cache the value of the
port at the start of run(). For array values, this could be very
wasteful. Requiring that port updates be synchronous with run()
imposes a considerable burden on the host. Ardour would have a hard
time doing this, for example.
My impression has been that we assume LADSPA plugins are able to
handle port updates at any time; in reading the header, I see that the
language is ambiguous:
Control data has a single value at the start of a call to the
`run()' or `run_adding()' function, and may be considered to remain
[at] this value for its duration.
So its not clear what to do about that. I know that when I wrote that
line or edited it from Richard's original, my mental model was like
that of the typical csound opcode:
float val = *portval;
while (nframes--) {
... use val ..
}
the "remain at this value" language meant that plugins don't have to
check back to see if it has changed during run(), rather than there
was a guarantee that it would not.
>> 2) GUI descriptor
>
>I think I prefer a system where DSP parts are GUI agnostic, and the GUIs
>live in thier own directory and can be asked what plugin(s) they support.
OK, I agree with that. In which case, no change to LADSPA would be
needed at all ...
>OTOH the concept of a preferred/recommended gui could be useful.
... except to support this. OTOH, i don't see this as so useful. the
chances of there being more than 1 GUI per plugin is slim; if there
is, its down the user to decide which one they prefer. so i would
propose no support in the LADSPA header for a GUI at all.
>I would like to bring up the idea of port default values again too.
OK, this is the proposed addition:
----------------------------------------------------------------------
/* Hint LADSPA_HINT_DEFAULT_* indicates that in the absence of
other information (such as a preset or user preferences) a port
should be set to the suggested initial value. Notice that this
hint is valid only for control ports, and should not be set for
audio ports (hosts should ignore it if it is).
HINT_DEFAULT_{MIN,MID,MAX} all require that the HintDescriptor
has HINT_BOUNDED_ABOVE and/or HINT_BOUNDED_BELOW set, as required
to compute the default value.
*/
#define LADSPA_HINT_DEFAULT_ZERO 0x40 /* set to 0.0 */
#define LADSPA_HINT_DEFAULT_ONE 0x80 /* set to 1.0 */
#define LADSPA_HINT_DEFAULT_MIN 0x100 /* set to min */
#define LADSPA_HINT_DEFAULT_MID 0x200 /* set to min+(max-min/2) */
#define LADSPA_HINT_DEFAULT_MAX 0x400 /* set to max */
#define LADSPA_IS_HINT_DEFAULT_ZERO ((x) & LADSPA_HINT_DEFAULT_ZERO)
#define LADSPA_IS_HINT_DEFAULT_ONE ((x) & LADSPA_HINT_DEFAULT_ONE)
#define LADSPA_IS_HINT_DEFAULT_MIN ((x) & LADSPA_HINT_DEFAULT_MIN)
#define LADSPA_IS_HINT_DEFAULT_MID ((x) & LADSPA_HINT_DEFAULT_MID)
#define LADSPA_IS_HINT_DEFAULT_MAX ((x) & LADSPA_HINT_DEFAULT_MAX)
----------------------------------------------------------------------
>Per-plugin versioning could be worth considering too.
why would you put v1.0 and v2.0 plugs in the same file?
--p
This archive was generated by hypermail 2b28 : Thu Dec 06 2001 - 17:52:26 EET