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@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev