FreeG vs. Trim

[mhschmieder]

Actually, after comparing the rendered track (real-time vs. bounce; I stopped trusting bounce years ago except for final stem bounces pre-mastering, where there aren't any aux effects), I realized it still wasn't "there" yet regarding AmpliTube, even if the FreeG vs. Trim issue was solved at 128 for the buffer size.

When I went to a buffer size of 64, I finally got as cohesive and phase-aligned final bass combined track as with the "pre-adjustment" of the DI by one tic when using buffer size of 1028.

Going to 32 got different results, but surprisingly seemed slightly less cohesive.

Switching to real-time vs. pre-fen also got different results. I tried that at a buffer size of 64 and didn't notice a strong difference in terms of phase cohesion, so decided to switch back to pre-fen mode.

I read the relevant parts of the manual (p. 832 and surrounding parts, mostly), and it gave me no real concern regarding pre-gen vs. real-time. It does, however, mention the effect of using processing plug-ins on axes and/or ones that go from mono-to-stereo, plus a few other factors, but NONE of those factors apply to my bass tracks.

Not as sure I have this thing figured out as I thought, but at least my new workaround of using a buffer size of 64 -- at least when working on bass tracks -- is better than pre-adjusting an in-time DI track just so its post-processed result lines up with the mic tracks during mix-down of the bass stem.

As was mentioned in the other threads on the topic of Automatic Delay Compensation, this appears to be a DP8 bug that might even have crept into later DP7 releases.

[mhschmieder]

Interestingly, it's only at the intro where I got different results for 64 vs. 128 as the buffer setting, using AmpliTube, and I also got different results if I went back and re-rendered the brief bass appearance in the intro after the song was done rendering in real time, at any buffer setting.

The rest of the song (there is a pause after the intro, and the bass comes in near the end of the intro anyway, around bar 10), is 100% identical when using a buffer size of 128 or below, and is repeatably so. That is quite a relief, after the scare I got on the wild variation at the intro. But note that it does also still reinforce the difference vs. a buffer size of 1028.

I was able to creep up my buffer size again to 128 after noticing that I had forgotten to disable plug-ins on my stems when I went back to recreate the bass stem from the individual bass tracks.

The bottom line is that delay compensation is not working as well as it should, given that I'm not really using much processing or handling many tracks at a time. The most is six tracks, when I combine the drum overheads into a stem before doing the final drum set mix (also six tracks at that point; six stems into a final drum stem).

[EMRR]

Thanks for the report.

[mhschmieder]

As another point of reference, I got different audio in two consecutive takes the other day, when I had a lot (e.g. 24) of plug-ins assigned across six drum overhead tracks being mixed to a subgroup, with buffer setting at 128. I had to go to a buffer of 64 to get consistent results.

[bayswater]

You had to go to a smaller buffer to get consistent results?

[mhschmieder]

Yep. Every time, on everything I do. In order not to get CPU overload though, I'm trying to go no lower than 128 when dealing with more than a couple of tracks and more than a few plugs at a time. This is when working at 48 kHz. I haven't opened my 96 kHz projects this week.