Automation resolution and update rate: fundamentally flawed
Posted: Mon Feb 25, 2013 7:39 pm
Apparently, the automation in Live is fundamentally flawed for several reasons, with unacceptably low resolution and update rates as a result. Moreover, results can be highly inconsistent, depending on tempo changes used.
The rate at which automation envelopes update the target parameter value seems to depend on: (1) the steepness of the envelope curve, and (2) the musical tempo (BPM), and (3) also seems to be tied to the updating speed of the display.
Of course, the automation update rate should not depend on the steepness of envelope curve or playback tempo at all. Moreover, the speed used to display parameter values should not be intrinsically tied to the speed used for actual processing in a 1:1 relation. 'Lazy' updating is of course acceptable or even preferred, but that is not the case at all for audio processing, MIDI, etc.
For an illustrative, simple example: when Live is playing at its default tempo of 120 BPM, automating a 'sweep' of a parameter value across the entire range (in a straight line from its maximum to its minimum value, or vice versa), stretching 120 measures, looks like this:
One would expect a smooth automation. However, that is not what happens at all. See this screen capture video (1.5 MB QuickTime .mov).
In this very basic and simple example case, we can clearly observe an update frequency of only 4 Hz at the default tempo of 120 BPM, and that Live uses only 960 steps, i.e. a resolution which is slightly lower than 10bit (1024 steps). Whereas most plug-ins have a 32bit floating point range for their parameter values, 'stepping' at such an extremely low resolution is simply shocking. Before you ask: these fundamental flaws also affect the automation of parameters in third party plug-in used in Live, it is not restricted to Live's native devices. It seems to affects every single parameter that can be automated in Live.
The same goes for the update frequency of only 4 (!!!) Hz, i.e. 4 updates per second. At this tempo (which is not exceptional or extreme in any way), that is only two parameter value updates for every beat. That is already quite a low resolution for notes (e.g. try quantizing all notes to a 1/8th notes grid), let alone for automation.
As if this weren't enough cause for alarm, things can even get much worse, because there is another fundamental design flaw that amplifies the negative effects of this undesirable behavior. When increasing the tempo during playback (without e.g. 'jumping' the playhead in the scrub area, moving devices around, or anything else that causes Live to very quickly stop and restart playback), the update frequency apparently gets 'stuck' on the update frequency used at the initial tempo. For an extreme example, that magnifies the effect of this second fundamental design flaw on the first to make it most apparent, look at the next screen capture video of this example case demonstrating the issue (1.4 MB QuickTime .mov), where the tempo rises very fast from an initial tempo of 20 BPM to 960 BPM (i.e. an increase with a factor of 48), and is stuck at an update rate of only 0.67 Hz.
Please download this Live set, and open it in (any version of) Live 8.x to confirm this issue for yourself.
PS: Even though it has been stated explicitly that Live 8.4.x beta testing is focused exclusively on new bugs, this still seemed to be the least inappropriate section of this forum to post about these issues. So please excuse me for posting in this section anyway, but of course, mods: feel free to move this post to another section, if that would somehow be deemed more appropriate.
The rate at which automation envelopes update the target parameter value seems to depend on: (1) the steepness of the envelope curve, and (2) the musical tempo (BPM), and (3) also seems to be tied to the updating speed of the display.
Of course, the automation update rate should not depend on the steepness of envelope curve or playback tempo at all. Moreover, the speed used to display parameter values should not be intrinsically tied to the speed used for actual processing in a 1:1 relation. 'Lazy' updating is of course acceptable or even preferred, but that is not the case at all for audio processing, MIDI, etc.
For an illustrative, simple example: when Live is playing at its default tempo of 120 BPM, automating a 'sweep' of a parameter value across the entire range (in a straight line from its maximum to its minimum value, or vice versa), stretching 120 measures, looks like this:
One would expect a smooth automation. However, that is not what happens at all. See this screen capture video (1.5 MB QuickTime .mov).
In this very basic and simple example case, we can clearly observe an update frequency of only 4 Hz at the default tempo of 120 BPM, and that Live uses only 960 steps, i.e. a resolution which is slightly lower than 10bit (1024 steps). Whereas most plug-ins have a 32bit floating point range for their parameter values, 'stepping' at such an extremely low resolution is simply shocking. Before you ask: these fundamental flaws also affect the automation of parameters in third party plug-in used in Live, it is not restricted to Live's native devices. It seems to affects every single parameter that can be automated in Live.
The same goes for the update frequency of only 4 (!!!) Hz, i.e. 4 updates per second. At this tempo (which is not exceptional or extreme in any way), that is only two parameter value updates for every beat. That is already quite a low resolution for notes (e.g. try quantizing all notes to a 1/8th notes grid), let alone for automation.
As if this weren't enough cause for alarm, things can even get much worse, because there is another fundamental design flaw that amplifies the negative effects of this undesirable behavior. When increasing the tempo during playback (without e.g. 'jumping' the playhead in the scrub area, moving devices around, or anything else that causes Live to very quickly stop and restart playback), the update frequency apparently gets 'stuck' on the update frequency used at the initial tempo. For an extreme example, that magnifies the effect of this second fundamental design flaw on the first to make it most apparent, look at the next screen capture video of this example case demonstrating the issue (1.4 MB QuickTime .mov), where the tempo rises very fast from an initial tempo of 20 BPM to 960 BPM (i.e. an increase with a factor of 48), and is stuck at an update rate of only 0.67 Hz.
Please download this Live set, and open it in (any version of) Live 8.x to confirm this issue for yourself.
PS: Even though it has been stated explicitly that Live 8.4.x beta testing is focused exclusively on new bugs, this still seemed to be the least inappropriate section of this forum to post about these issues. So please excuse me for posting in this section anyway, but of course, mods: feel free to move this post to another section, if that would somehow be deemed more appropriate.