On Wed, 2012-05-30 at 19:42 +1200, Jeff McClintock wrote:
In some cases, it is. In some cases, it is not, in which case you do
one of two things:
* Don't deliver them
* Add latency so you can
For band-limited interpolated parameters, to render frame 4 you need
'future' parameter values past frame 4. This is not a decision, but a
fact, inconvenient though it may be.
> Even when the automation is pre-recorded. E.g. smoothly ramping up a
There is no actual prediction of the future involved. Either the host
actually does know the future (because it is automated) or it fakes it
by offseting reality slightly. For transport changes, you just defer
the actual operation by this amount as well.
Note that the required delay is very small. If the transport change is
something coming from a UI thread, it is certainly not even significant
compared to the delay inherent in that button's action making its way to
the audio thread at all. Well below what a user would ever notice or
have to compensate for.
I don't know precisely what this delay, which I have been calling L, is,
but I know it's small. Fons probably knows what it has to be in
> Now you can say to the plugin 'process 100 samples' while specifying the
Except you can't do band-limited parameter interpolation in that case.
Zip zip click buzz. That's the problem.
The "future" thing is inherent to the requirement. The only question is
whether to make the host explicitly do this, or have the plugin
sometimes maybe interpret the control parameters with latency depending
on if it needs to.
IMO the case for the former is a strong one.
Linux-audio-dev mailing list