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@email-addr-hidden http://lists.linuxaudio.org/listinfo/linux-audio-devReceived on Tue May 29 16:15:02 2012
This archive was generated by hypermail 2.1.8 : Tue May 29 2012 - 16:15:02 EEST