Re: [LAD] : Plugin buffer size restrictions

On Wed, 2012-05-30 at 19:42 +1200, Jeff McClintock wrote:
> > I think providing synchronous control events, with 'future' values (at
> > least some distance L in the future) is the way to get that. Let's
> > pretend that the Ultimate Plugin Interface (UPI) 1.0 exists, works this
> > way, is stable and unmalleable, and all you have to work with to
> > deliver
> > your product (a plugin).
> >
> > >From the plugin author perspective: is there anything that is
> > *impossible* to do correctly?
> >
> > -dr
>
> I believe it simply impossible to reliable deliver 'future' parameter
> values.

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
> parameter over 1 second. You can't say to the plugin 'ramp this parameter
> over 1 second' - because partway through the 'ramp' the user can reposition
> the playback to another part of the song, or loop a section, or change the
> tempo, or hit 'Stop'. Any attempt to predict the future like that leads to
> kludgy hacks.

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
rigorous terms.

> Now you can say to the plugin 'process 100 samples' while specifying the
> parameter value at sample# 0 and also at sample# 99. That is how to specify
> a precise ramp (or section of a longer ramp) without providing future
> parameter values.

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.

-dr

_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Thu May 31 00:15:01 2012