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/