| 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
