Subject: [linux-audio-dev] changing control port values with LADSPA: a serious issue?
From: n++k (knos_AT_free.fr)
Date: Sat Mar 16 2002 - 21:07:47 EET
| 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.
axiom i:
parameters are variables made for human interaction
axiom ii:
human interaction is probably sufficiently defined by 3 parameters:
x, v = dx/dt, a = dv/dt (which humans interact with mostly)
i propose an hybrid model of 1) and 2) such as:
1/ automatable plugins provide a way to set the parameter as well
as its first and second instantaneous derivatives against time.
2/ the host calls process() N times to correctly approximate the
intended parameter curve
This archive was generated by hypermail 2b28 : Sat Mar 16 2002 - 20:02:35 EET