Subject: [linux-audio-dev] changing control port values with LADSPA: a serious issue?
From: Paul Davis (pbd_AT_Op.Net)
Date: Sat Mar 16 2002 - 14:59:27 EET
i have been dwelling on the issue on plugin parameter automation for
ardour in the last several days, and i am convinced (perhaps
incorrectly) that the current specification of LADSPA semantics for
control port values is wrong and deeply troublesome.
the current semantics, reiterated here recently by richard f., are
that a plugin can assume that a control port value will not change
during the call to process(). the motivations for this are simple, and
seemed pretty valid to me until i started to consider parameter
automation.
consider a simple case where you want to ramp a plugin parameter over
the course of a call to process. if you obey current LADSPA semantics,
the only ways to do this that i can think of are:
1) set the control port value to the end point, and pray that
the plugin will ramp to it, based on the last value.
2) decide on the step size, and call process() N times with
`step' frames, altering the control port each time.
(1) might work if we made it part of the semantics of how plugins are
supposed to operate. Fortunately at this time there are only 3 sets of
plugins (CMT, swh and the guy that wrote a suite of them including
recorders, ALSA/OSS plugins etc). We could change this and it wouldn't
be impossible for the change to take place. On the other hand, its not
a very nice thing to do, it puts a great burden on plugin authors, and
it prevents the host from controlling the shape of the parameter
changes.
(2) this works is the step size is large enough. but over on the
vst-plugins list, it seems de rigeur to interpolate at the sample
level, something like (for linear interpolation, for example):
float inc = new_control_port_value - last_control_port_value;
inc /= nframes;
while (nframes--) {
... generate a frame ...
parameter_value += inc;
}
You cannot reasonably simulate this by calling process() with an
argument of 1 frame over and over again - the cost is way to high and
you destroy any optimization in the plugin.
------------
From where I stand right now it seems impossible to implement plugin
parameter automation with this scheme. The VST approach is to feed a
list of timestamped (parameter change) events to the plugin before the
call to process(), and expect the plugin to respond to these events
during process(). This takes us back to all the event-centered
discussions we had here about MAIA. I'm not sure I like all the
details of VST's method for handling this, but I do know that plugin
parameter automation is a vital part of a modern DAW, and I need to
find a solution to this issue, and reasonably quickly.
I know that LADSPA contains an "S", and I agree entirely with
Richard's goals when he set out to find a common subset of several
existing application-specific features for inclusion into LADPSA,
along with the general idea that if you wanted higher-level
functionality, your app should wrap LADSPA plugins in its own
structure. The problem is that here we require additional lower-level
functionality that cannot be efficiently simulated with the existing
LADSPA mechanisms.
Does anybody have any concrete proposals or ideas? Did I miss some
glaringly obvious method for doing this?
--p
This archive was generated by hypermail 2b28 : Sat Mar 16 2002 - 17:58:26 EET