On Sun, May 27, 2012 at 09:59:29PM +0300, Stefano D'Angelo wrote: > If I understand correctly an implication would be that you get uniform > sampling of parameter signals with control rate = sample rate / > nframes. I assume that computing parameter trajectories basically > means interpolating, and that inevitably introduces some latency if > you want the audio and control streams to be in sync (e.g., nframes > for linear interpolation, 2 * nframes for splines, etc.).
Indeed, interpolation introcudes delay. If control values are delivered at a constant rate it's quite easy for a host to compensate for this. What is needed in that case is that the delay is *defined*. But there is anothor issue you touch on. If automation data is the result of 'real time' input, then that delay doesn't matter - the user, while creating the data using some GUI widget or a HW controller, will compensate for it because he/she simply has no other choice. Then, if the host delivers the data at the same time (w.r.t. the audio) as when it was recorded, then the plugin will do the same things and the user will hear the result he/she wanted. If OTOH the automation data is created by e.g. drawing some curves in a graphical interface (with probaby the audio wave- form as a reference) then you don't want that delay, and the host shoudl compensate for this. In most cases (general audio effects in a DAW) it just doesn't matter much. The only thing (apart from synthesis/instruments) that need accurate timing is the 'mute' function when used to remove unwanted noises etc. But that is usually handled by the host itself, and anyway automation is not the best way to deal with such things - editing is. Ciao, -- FA A world of exhaustive, reliable metadata would be an utopia. It's also a pipe-dream, founded on self-delusion, nerd hubris and hysterically inflated market opportunities. (Cory Doctorow) _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/listinfo/linux-audio-dev
