Automation Inaccuracies

[John_T]

I just watched this youtube vid showing the inaccuracies in how automation is interpolated by various Daws. Bitwig fairs pretty badly

https://www.youtube.com/watch?time_cont ... 4ucvUoii-c

Someone in the youtube comments said that in the case of FL Studio he should try using a FBalance. I guess this is like Tool in Bitwig, so I decided to do a similar test in bitwig.

automation fades.png

Is this type of interpolation the same with all automations in Bitwig? Does the same thing happen with modulators?

[John_T]

The green clip is a Sinewave bounced from a Grid oscillator. The Yellow clip is the bounce with the Tool - Gain automated from 0dB to -36dB then back to 0dB. The orange clip is the same done to the Mixer - Fader.

[x.iso]

I've tried some other parameter modulations and results vary, but mostly follow same trend. Modulators are much more precise. with about 0.01ms accuracy or so. For typical C3 Square wave it would fade in/out just a fraction of the wave phase, so I think it's good enough.
In case of automations, there are certainly much worse examples out there, also smoother fade-in prevents clicks, although it's excessive for that purpose and should be an option.

[John_T]

Thank you for the info x.iso

[Yokai]

Curious what resolution the grid is at in your screenshots. As for why they do this and whether it’s “bad” (as Admiral Bumblebee implies in the vid you saw), my first challenge is to split your original clip and then apply autofade to that split-out clip. Then bounce the split-out and auto-faded clip. Then compare that to your tests above.

Point being, is this concern much ado about nothing? Obviously the design intent is to prevent clicks from automation moves, just like microfades are intended to prevent clicks from audio event splits.

[x.iso]

For general use yeah it will save you from clicks and such, but as there's a setting for auto-fades, there should be one for automations as well.

[abique]

Hard cut for smooth transitions!

[John_T]

Hi Yokai. Thank you very much for your tutorials on youtube. You have greatly helped me to gain a deeper understanding of Bitwig

It is this need for a deeper understanding that caused me to share the video and to test it out myself in Bitwig.

I had no clue about this behaviour within the daw, hence the sharing here.

I am yet unsure whether it is a feature or a bug, or whether it is a good thing or a bad thing.

For me, the main thing that came across from Admiral Bumblebee's video is the large difference in the implementation of automation interpolation between the differing Daw's.

[Yokai]

Hi Yokai. Thank you very much for your tutorials on youtube. You have greatly helped me to gain a deeper understanding of Bitwig

It is this need for a deeper understanding that caused me to share the video and to test it out myself in Bitwig.

I had no clue about this behaviour within the daw, hence the sharing here.

I am yet unsure whether it is a feature or a bug, or whether it is a good thing or a bad thing.

For me, the main thing that came across from Admiral Bumblebee's video is the large difference in the implementation of automation interpolation between the differing Daw's.

So FWIW, I tested with the Mixer Volume automation, and the steepest early section of the ramp (on the right side, where the automation volume goes up again) is roughly 10ms long. The full ramp is 21 ms long.

Now consider that when you do Clip > Autofade, the length of the applied fades is 6 milliseconds.

IMO, in the context of typical automation lanes one is likely to use in a real project, it’s a non-issue. I mean, are most producers going to use a stepped automation cut on a kick or snare track? Because yeah, that would eat Into the transient of the first hit after the stepped cut. But who’s really likely to use stepped cuts this way on a kick or snare track?

[wavedigit]

But who’s really likely to use stepped cuts this way on a kick or snare track?

I usually like to add FX to my kick track (which frequently includes various revebs and delays). The first hit of the kick will be different from subsequent hits since subsequent ones have various tails of other FX laid over them, so I usually have a "dummy" clip of the kick track running (but with amp at the end set to silent), but when I want to bring the kick in, I trigger a clip with automation that sets that amp to 0db, thus letting all of the previous signal through.

Of course I could bounce it, but then it would be subject to this behavior. Plus, if I wanted to go back and tweak some parameters in the original FX chain, I'd have to re-bounce it again.

[Yokai]

Okay folks, it's time to stop worrying about this entirely. It has nothing to do with the automation lanes themselves (or their "interpolation"). Instead, it revolves entirely around the ballistics/ramp/lookahead behavior of any one device or VST that is reacting to the automation. This is why, for example, in the OP's screenshot above you see a different result depending on whether they were using Bitwig's Tool device or the track's Mixer > Volume.

Below is a screenshot showing a stepped cut on the Volume of MUtility. (Which is my tool of choice for volume automation in Bitwig, because it goes down to -inf and enables me to still make track fader adjustments all the way through the mastering phase of a project.)

So in this screenshot, you can see that the ramp down and ramp up from the stepped automation move are QUITE different from either Tool or Mixer > Volume. For one, the total length of each ramp is only 10 ms from -inf to 0 dBFS (or vice versa). For two, you can see that the ramp is evenly split onto BOTH sided of the actual stepped change in the automation lane. That's right, the MUtility VST is obviously using some degree of lookahead to "see" those automation points coming ahead of time, and it's choosing to split its total ramp length evenly in front of and behind the stepped automation change. You can also therefore deduce that every native DAW device or VST that manipulates volume/gain envelopes is choosing BY DESIGN to minimize/eliminate clicks and pops from sudden changes, by forcing their min-max jumps to occur over a ramped amount of time. Some ramps with linear curves (like MUtility), other ramps with non-linear curves (like Tool or Mixer > Volume).

The conclusion I draw is that the automation lanes are simply timing events that are very accurate, and it's up to any individual native DAW device or VST to decide how to respond to those timing events. (I also conclude that Admiral Bumblebee could have tested a few VSTs before deciding to make such an alarmist video.) Move along, nothing to see here. ^.^

[Robert Randolph]

Okay folks, it's time to stop worrying about this entirely. It has nothing to do with the automation lanes themselves (or their "interpolation"). Instead, it revolves entirely around the ballistics/ramp/lookahead behavior of any one device or VST that is reacting to the automation. This is why, for example, in Admiral Bumblebee's video you saw a different result depending on whether they were using Bitwig's Tool device or the track's Mixer > Volume.

Below is a screenshot showing a stepped cut on the Volume of MUtility. (Which is my tool of choice for volume automation in Bitwig, because it goes down to -inf and enables me to still make track fader adjustments all the way through the mastering phase of a project.)

So in this screenshot, you can see that the ramp down and ramp up from the stepped automation move are QUITE different from either Tool or Mixer > Volume. For one, the total length of each ramp is only 10 ms from -inf to 0 dBFS (or vice versa). For two, you can see that the ramp is evenly split onto BOTH sided of the actual stepped change in the automation lane. That's right, the MUtility VST is obviously using some degree of lookahead to "see" those automation points coming ahead of time, and it's choosing to split its total ramp length evenly in front of and behind the stepped automation change. You can also therefore deduce that every native DAW device or VST that manipulates volume/gain envelopes is choosing BY DESIGN to minimize/eliminate clicks and pops from sudden changes, by forcing their min-max jumps to occur over a ramped amount of time. Some ramps with linear curves (like MUtility), other ramps with non-linear curves (like Tool or Mixer > Volume).

The conclusion I draw is that the automation lanes are simply timing events that are very accurate, and it's up to any individual native DAW device or VST to decide how to respond to those timing events. (I also conclude that Admiral Bumblebee could have tested a few VSTs before deciding to make such an alarmist video.) Move along, nothing to see here. ^.^

The video was about testing fader automation. The point is that you find out if you get what you see, THAT is what makes bitwig's response bad.

If it showed the fade, or if it was documented then everything would be fine.

Testing plugins is another topic... and since this is a multipart series, I assume you can figure out what may be coming.

(And calling it alarmist for showing how the product works is... odd.)

[Yokai]

The video was about testing fader automation. The point is that you find out if you get what you see, THAT is what makes bitwig's response bad.

If it showed the fade, or if it was documented then everything would be fine.

Testing plugins is another topic... and since this is a multipart series, I assume you can figure out what may be coming.

(And calling it alarmist for showing how the product works is... odd.)

Robert, I really admire a lot of your content. I just think in this one case you gave the wrong impression in some ways. In the entire first two minutes of the video, you never mention that this episode is about fader automation. Instead, you just explain (I think incorrectly) that stepped automation points are somehow interpolated by the DAW into smoother curves, and it's those smoother, interpolated curves that are fed to whatever thing is being automated.

Again, I'm not sure that's accurate (based on my limited testing)--I don't think a DAW is interpolating stepped automation points. Instead, I think each device/VST (including the "mixer" or "track" controls) is left to its own design how to react to sudden (stepped) value changes.

I think a more accurate premise--and conclusion--would have been to state that the native "track/mixer VOLUME control" in each DAW does not respond the same way to sudden/stepped automation changes. Or perhaps if you'd simply prefaced all the interpolation stuff with "this is what the track/mixer VOLUME control in each DAW does in response to the timing events of the automation lanes..."?

I mean, I saw two different reactions, in two different places, to your video, and they both were of the general tone "oh wow, Bitwig automation in general is fuxxored and inaccurate!"

And I could be wrong in my own conclusions. I'm open to that possibility. Sorry if I ruffled any feathers, because that wasn't intended.

[Robert Randolph]

The video was about testing fader automation. The point is that you find out if you get what you see, THAT is what makes bitwig's response bad.

If it showed the fade, or if it was documented then everything would be fine.

Testing plugins is another topic... and since this is a multipart series, I assume you can figure out what may be coming.

(And calling it alarmist for showing how the product works is... odd.)

Robert, I really admire a lot of your content. I just think in this one case you gave the wrong impression in some ways. In the entire first two minutes of the video, you never mention that this episode is about fader automation. Instead, you just explain (I think incorrectly) that stepped automation points are somehow interpolated by the DAW into smoother curves, and it's those smoother, interpolated curves that are fed to whatever thing is being automated.

Again, I'm not sure that's accurate (based on my limited testing)--I don't think a DAW is interpolating stepped automation points. Instead, I think each device/VST (including the "mixer" or "track" controls) is left to its own design how to react to sudden (stepped) value changes.

I think a more accurate premise--and conclusion--would have been to state that the native devices and native "track/mixer" controls in each DAW do not respond the same way to sudden/stepped automation changes. Or perhaps if you'd simply prefaced all the interpolation stuff with "this is what the track/mixer VOLUME control in each DAW does in response to the timing events of the automation lanes...?

And I could be wrong in my own conclusions. I'm open to that possibility. Sorry if I ruffled any feathers, because that wasn't intended.

There is a text article with all my videos that go into more detail. I mistakenly thought that since I was only testing fader automation in the content that it was obvious that this was only about fader automation. I will make sure to be more explicit in the future.

To the rest of your post, a new article/video is coming very soon™ that already addresses most your concerns. I'm trying to put the finishing touches on it today, but I've already found a new automation bug in a DAW so that's taken up half my morning already

Regardless of how different devices work, the biggest takeaway is that the render is not what you are shown, and not what is documented. If you want to know what your product is doing then you are left to spend hours doing testing, stumble upon an error, or rely on losers like me that waste their time doing these inane things.

I've taken your commentary to heart though. Unless I die or lose both my arms (or similar), there is much more content coming on the topic of how DAWs differ and specifically on automation. I try to keep the articles/videos short and focused.

I'm very glad you tested these things for yourself too, thank you! At no point should anyone ever take someone else's testing at face value when it's so easy to do it yourself

Please keep the feedback coming. I know I can be argumentative at times, but it's that very nature that makes me so inquisitive to begin with.

[Yokai]

There is a text article with all my videos that go into more detail. I mistakenly thought that since I was only testing fader automation in the content that it was obvious that this was only about fader automation. I will make sure to be more explicit in the future.

To the rest of your post, a new article/video is coming very soon™ that already addresses most your concerns. I'm trying to put the finishing touches on it today, but I've already found a new automation bug in a DAW so that's taken up half my morning already

Regardless of how different devices work, the biggest takeaway is that the render is not what you are shown, and not what is documented. If you want to know what your product is doing then you are left to spend hours doing testing, stumble upon an error, or rely on losers like me that waste their time doing these inane things.

I've taken your commentary to heart though. Unless I die or lose both my arms (or similar), there is much more content coming on the topic of how DAWs differ and specifically on automation. I try to keep the articles/videos short and focused.

I'm very glad you tested these things for yourself too, thank you! At no point should anyone ever take someone else's testing at face value when it's so easy to do it yourself

Please keep the feedback coming. I know I can be argumentative at times, but it's that very nature that makes me so inquisitive to begin with.

No harm no foul! I'm blunt too--but try to be diplomatic and objective. I don't always come across that way though.

Seriously, I think this series you're doing is great content--and I agree with the general message behind this series! For example, I've long been a fan of reminding people that letting your DAW do realtime up/down sampling of sample clips with differing sample rates (i.e., mixing 44100 samples with 48000 samples in the same project) is a really really terrible idea because every single DAW has shitty realtime SRC. And a lot of DAWs (like Bitwig!) even have shitty export SRC. (Ableton's export SRC, by contrast, is nearly as good as the excellent SRC in RX7.)

So I'm in your court on this subject in general.