On 05/29/2012 01:03 AM, Fons Adriaensen wrote:
Things are different if the control data was not generated 'live' but e.g. created in an graphical automation editor using a displayed recorded waveform - the one the plugin will operate on - as the time reference. In that case users will not expect an offset of control w.r.t. audio. But otoh, even such data will probably be edited by 'trial and error' - by listening to the result instead of trusting the graphical input blindly - which means that even in this case the user will somehow compensate for the delay (if it is short enough).
The graphical environment would lead to the expectation that control points in the automation editor and the waveform view are strictly in one timeline, no delay.
It should be possible and provided for, that parts of automation recorded live and parts created graphically are mixed and also that recorded automation will be edited.
I guess that would mean that an automation editor has to show the result of the control values, not the values themselves. So on playback, the automation would be send with negative delay (requiring latency on the "Play" command ...)
-- Thorsten Wilms thorwil's design for free software: http://thorwil.wordpress.com/ _______________________________________________ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
