30 May
2012
30 May
'12
9:42 a.m.
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).
I believe it simply impossible to reliable deliver 'future' parameter
values.
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.
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. Apologies if that's what you meant. (I classify 'future'
values in this example as being later than sample #99 ).
Best Regards,
Jeff
From the plugin author perspective: is there
anything that is
*impossible* to do correctly?
-dr 
30 May
30 May
7:21 p.m.
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.
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).
I believe it simply impossible to reliable deliver 'future' parameter
values. From the plugin author perspective: is there
anything that is
*impossible* to do correctly?
-dr 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
4555
days inactive
4555
days old
linux-audio-dev@lists.linuxaudio.org
1 comments
2 participants
participants (2)
-
David Robillard -
Jeff McClintock