Automation resolution and update rate: fundamentally flawed

Locked
banned
Posts: 59
Joined: Wed Sep 15, 2010 3:10 pm

Automation resolution and update rate: fundamentally flawed

Post by banned » 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:

Image

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.
Last edited by banned on Tue Mar 19, 2013 8:15 pm, edited 1 time in total.

AustinThumper
Posts: 110
Joined: Sat Feb 02, 2013 2:59 am

Re: Automation resolution and update rate: fundamentally flawed

Post by AustinThumper » Mon Feb 25, 2013 8:52 pm

Yep, it happens here too. Have you tried reversing the ramp (sweep up)? Very different results!
Spoiler alert - it works in the rising direction, on my system at least. An odd bug, perhaps?

Live Suite 8.3.4/MOTU 828mk2/Win7


edit: I changed my automation curve to start at 0, max out midway, and go back to zero. Works fine..

and again - I can trigger this stepping behavior when the starting "dot" is right at the first of the clip. If I nudge it to the right, I get smooth automation..
Live 9.6 Suite / Max 7.2 / REAPER / Reaktor 6 / Win10 64bit / 4.2GHz i7 / 32GB DRAM / SSD / 828mk3 / 4 x HR824 / QX25 / HPD-15 / Sonor club kit / Mother-32 and a growing Eurorack.

banned
Posts: 59
Joined: Wed Sep 15, 2010 3:10 pm

Re: Automation resolution and update rate: fundamentally flawed

Post by banned » Mon Feb 25, 2013 9:29 pm

AustinThumper wrote:Yep, it happens here too. Have you tried reversing the ramp (sweep up)? Very different results!
Spoiler alert - it works in the rising direction, on my system at least. An odd bug, perhaps?

Live Suite 8.3.4/MOTU 828mk2/Win7


edit: I changed my automation curve to start at 0, max out midway, and go back to zero. Works fine..

and again - I can trigger this stepping behavior when the starting "dot" is right at the first of the clip. If I nudge it to the right, I get smooth automation..
Thanks for confirming, Austin, but as far as I have tested, your additional analysis is incorrect. I guess you've been adjusting the envelope while playing? In this context that also counts as "anything else that causes Live to very quickly stop and restart playback", as I have stated it in the OP (admittedly, it is not very clear what sort of cases may fall in this broad category).

When you adjust the envelope while playing, that will neutralize the effect of the steep rise in tempo. However, when played from the start, the exact same thing happens when the ramp goes upwards. The direction seems to be completely irrelevant; it's only the steepness of the curve that matters.

Image

Moreover, such a change only neutralizes the magnifying effect of the second fundamental flaw on the first one. That first, imho much more important issue *remains*. What you call "smooth automation" is probably in fact still only 4 Hz, at less than 10bits resolution (except where you have a maximum halfway, at 61.1.1, that would double the update rate to 8 Hz - still extremely low, at least in my book).

Please check your findings again. :) If you can't reproduce, I'll be glad to illustrate and explain in more detail. Thanks!
Last edited by banned on Mon Feb 25, 2013 9:34 pm, edited 1 time in total.

H20nly
Posts: 16057
Joined: Sat Oct 27, 2007 9:15 pm
Location: The Wild West

Re: Automation resolution and update rate: fundamentally flawed

Post by H20nly » Mon Feb 25, 2013 9:30 pm

banned wrote: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.
8O oof. curious.

where are you getting these numbers?

AustinThumper
Posts: 110
Joined: Sat Feb 02, 2013 2:59 am

Re: Automation resolution and update rate: fundamentally flawed

Post by AustinThumper » Mon Feb 25, 2013 9:53 pm

I'm not sure what you expect this to sound like (when it works), but on my system, once I move the start point off of the very start, or click near the start of the clip in the scrub area , it is a smoothly descending tone. Maybe it's stepped I suppose...

I'm not changing anything once it's playing. I'd post a screen capture but I can't. :cry:
Live 9.6 Suite / Max 7.2 / REAPER / Reaktor 6 / Win10 64bit / 4.2GHz i7 / 32GB DRAM / SSD / 828mk3 / 4 x HR824 / QX25 / HPD-15 / Sonor club kit / Mother-32 and a growing Eurorack.

banned
Posts: 59
Joined: Wed Sep 15, 2010 3:10 pm

Re: Automation resolution and update rate: fundamentally flawed

Post by banned » Mon Feb 25, 2013 9:56 pm

H20nly wrote:
banned wrote: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.
8O oof. curious.

where are you getting these numbers?
(That is explained in the video's linked above. But I'll explain here, as that should make the discussion easier to follow - and not everybody has decent enough internet connectivity at all times to download a few megabytes, of course.)

One approach to seeing it quite clearly, with the example set I linked to above at least, is to set the tempo manually to as low as 30 BPM (i.e. overriding the automation of the tempo on the master track, or just deleting the envelope entirely, whatever suits you best). At this speed, you will quite clearly see the update rate at only 1 Hz (which should be slow enough to count and confirm the timing, more or less, using nothing but the naked eye and ear).

Then double the tempo to 60 BPM, you'll see and hear the rate doubling as well, from 1 to 2 Hz. Then double the tempo once again from 60 to 120 BPM, and you're at exactly 4 Hz. Various measurements all confirm this (i.e. recording audio output and counting samples, recording screen capture videos and counting frames, etc.).

The resolution can be induced as follows: 120 measures at 120 BPM = 240 seconds. Multiply by 4 = 960 steps between minimum and maximum. Since 960 is only slightly less than 1024 *and much more than 512), it can be stated that the resolution is slightly less than 10bit (2^10 = 1024, and 2^9= 512).

banned
Posts: 59
Joined: Wed Sep 15, 2010 3:10 pm

Re: Automation resolution and update rate: fundamentally flawed

Post by banned » Mon Feb 25, 2013 10:13 pm

AustinThumper wrote:I'm not sure what you expect this to sound like (when it works), but on my system, once I move the start point off of the very start, or click near the start of the clip in the scrub area , it is a smoothly descending tone. Maybe it's stepped I suppose...

I'm not changing anything once it's playing. I'd post a screen capture but I can't. :cry:
When you start beyond the tempo change, indeed, that initial tempo change is not going to affect it, because it "never happened" (there is no 'seeking' behavior for tempo automation, obviously). And clicking in the scrub area, as mentioned in the OP, does stop and start playback very quickly. So those cases were already accounted for in the description of the issue in the OP, as far as I can see. Perhaps I can make that clearer though, so I'd be glad to hear suggestions for improvement of the description.

I guess the best I can tell you, is to ignore the magnifying effect of the tempo change for now, and just focus on what happens if you play the set at 30 BPM - I mentioned how one bug makes the other even more obvious, but that apparently is missing its point, at least for you: you're apparently not seeing the first one anymore because of the 'smoothness' in comparison to the extreme. Because in comparison, sure, 960 steps are much smoother than only 22 steps. I'll grant you that. But 960 steps is still extremely low, given the fact that most plug-in parameters use a 32 bit floating point resolution internally.

Also note that a range of 10 Hz to 2 Khz is still quite small; divided by 960 that makes only very small steps measured in Hz, which may indeed be quite hard to hear. But if you do the same thing to sweep a resonant peak on the EQ from 30 Hz to 22 kHz, the difference becomes much larger, and every step becomes quite clearly audible. I'll post an example later that makes it easier to hear the stepping.
Last edited by banned on Tue Mar 19, 2013 8:22 pm, edited 1 time in total.

H20nly
Posts: 16057
Joined: Sat Oct 27, 2007 9:15 pm
Location: The Wild West

Re: Automation resolution and update rate: fundamentally flawed

Post by H20nly » Mon Feb 25, 2013 10:15 pm

banned wrote:(That is explained in the video's linked above. But I'll explain here, as that should make the discussion easier to follow - and not everybody has decent enough internet connectivity at all times to download a few megabytes, of course.)
thanks.

i am at work. i typically avoid watching streaming video/downloads while i am... so the break down is appreciated.

in a way i'm glad that your answer was determined using math rather than some white paper type programming specifications that amount to: no change, keep upgrading... i feel like there is still hope of change/resolution with the former.

banned
Posts: 59
Joined: Wed Sep 15, 2010 3:10 pm

Re: Automation resolution and update rate: fundamentally flawed

Post by banned » Mon Feb 25, 2013 11:01 pm

H20nly wrote:
banned wrote:(That is explained in the video's linked above. But I'll explain here, as that should make the discussion easier to follow - and not everybody has decent enough internet connectivity at all times to download a few megabytes, of course.)
thanks.

i am at work. i typically avoid watching streaming video/downloads while i am... so the break down is appreciated.

in a way i'm glad that your answer was determined using math rather than some white paper type programming specifications that amount to: no change, keep upgrading... i feel like there is still hope of change/resolution with the former.
Well, my analysis was not based on maths, but on common sense, logic, and empirical facts. However, to express my findings in quantitative measures, I wanted to use musical tempi (i.e. 1/8 notes) and Hertz for the automation update rate, and bit depth for resolution, since these are more familiar and objective concepts in this context than "whoah! automation sucks really bad in Live! It's painfully slooow... and VERY steppy!" ;) So I just messed around until the numbers/ratios became nice and round, which makes using some basic arithmetic ever so slightly more feasible for people who suck at maths, like me. :)

Btw, the movie files can be downloaded, too, if that's more convenient. They're simply QuickTime .mov files hosted in my Dropbox. They should only appear inline if your browser is smart enough to launch some sort of QuickTime player automagically. Otherwise, just right-click and save.

banned
Posts: 59
Joined: Wed Sep 15, 2010 3:10 pm

Re: Automation resolution and update rate: fundamentally flawed

Post by banned » Mon Feb 25, 2013 11:39 pm

Here is another example set, with a second track, that may serve to further illustrate the issues. Just download it, then FIRST TURN DOWN YOUR SPEAKERS, AS THIS MAY REALLY HURT YOUR EARS, and then play it.

Again, a downward sweep over 120 measures, but this time it comes from all the way up at 22kHz down to 30 Hz. No automated tempo changes this time; just use whatever tempo suits you (these tempi simply happen to correspond to nice integer numbers for all the values concerned, that's all); but I do recommend starting playback at 30 BPM, and once you clearly notice the stepping, increase the tempo to 60, then later on to 120 BPM (i.e. more commonly used, arguably more ;regular' or 'realistic' tempi). Note that in the first few measures, the frequency of the sound may be too high to hear the effect very clearly, so I would suggest starting playback at bar 17 or so.

In this second example, I have used yet another fundamental flaw to make the first one more obvious, namely a lack of adequate headroom, leading to some nasty digital artefacts. What is remarkable in this particular context, is that the sound of this digital distortion changes quite audibly (especially in the higher frequencies, where there seems to be a lot more aliasing) at the automation update rate. At 30 BPM, the artefacts remain more or less consistent in their sound for a second, then suddenly change to a audibly different sound after a second, and so on.

The second track contains an Operator generating white noise (more or less, at least), followed by a resonant filter in the form of an EQ8 that is set up to use all bands simultaneously. With 8 'bell' shaped bands resonating at the same frequency, a sinusoid wave shape is generated between 30 Hz and 22 kHz (i.e. the range of the frequency parameter in EQ8). The rise in output level caused by these 8 * +15dB peaks drowned out the noise in the other parts of the spectrum almost completely, and is then put through a Compressor device to bring the level back down again. Finally, the compressor is followed by a series of Utility devices to lower the level by a further -90 db (3 * -30dB).

AustinThumper
Posts: 110
Joined: Sat Feb 02, 2013 2:59 am

Re: Automation resolution and update rate: fundamentally flawed

Post by AustinThumper » Mon Feb 25, 2013 11:57 pm

^ I think you might have just invented yourself a new genre!
Live 9.6 Suite / Max 7.2 / REAPER / Reaktor 6 / Win10 64bit / 4.2GHz i7 / 32GB DRAM / SSD / 828mk3 / 4 x HR824 / QX25 / HPD-15 / Sonor club kit / Mother-32 and a growing Eurorack.

banned
Posts: 59
Joined: Wed Sep 15, 2010 3:10 pm

Re: Automation resolution and update rate: fundamentally flawed

Post by banned » Tue Feb 26, 2013 12:47 am

AustinThumper wrote:^ I think you might have just invented yourself a new genre!
From an artistic perspective, sure, such artefacts can be useful. I can certainly enjoy them very much myself at times, and do use them in various contexts. No debate there. :)

From a technical perspective, however, the story is quite different. I simply expect a modern DAW to be programmed much better than that - this just seems to be a matter of very poor programming / design, as floating point DSP maths has plenty of dynamic range. Note that I can do the exact same thing in other DAWs, and hardly have any such artefacts. In fact, even if I do the same with 10 * 8 EQ bands, generating resonant peaks of many hundreds of dB, it still sounds infinitely cleaner than Live. No aliasing, no clipping, no bit-crushing. In Live, it is not as much of a choice as a restriction: you just run out of headroom very quickly. Imho it's only really artistic if it is the result of choice.

Of course, one can argue that that my choice not to respect this restriction here is a choice, too. But as I hope I have made clear, in this particular case, it simply serves to make the issue in the OP clearer.

I'll make another post for this limited headroom / nasty artefacts stuff later. ;)

banned
Posts: 59
Joined: Wed Sep 15, 2010 3:10 pm

Re: Automation resolution and update rate: fundamentally flawed

Post by banned » Mon Apr 08, 2013 2:22 pm

banned wrote:Here is another example set, with a second track, that may serve to further illustrate the issues. Just download it, then FIRST TURN DOWN YOUR SPEAKERS, AS THIS MAY REALLY HURT YOUR EARS, and then play it.

[...]

In this second example, I have used yet another fundamental flaw to make the first one more obvious, namely a lack of adequate headroom, leading to some nasty digital artefacts. [...]
This issue seems to have been fixed for Live 9.x (cf. the 9.0.3b3 Release Notes), but still exists in all versions of Live 8.x (up to the most recent version, 8.4.1b1):
The Compressor device does not clip input signals at +20 dB anymore.
PS: Thanks for fixing it for Live 9.x, Ableton, but no thanks at all for your complete silence on this issue (and many others) ever since it was reported. Having an open and reasonable discussion on technical issues is apparently not your strongest point, to put it mildly. :roll:

Locked