Hello!
I have the need to record stems in real time for an album I'm working on. We are mixing through analog gear.
the way I have figured to do this is to set up audio tracks as Aux buses and recording through them I.E. drum bus output gets routed to this stem audio track then to master bus. this works great for all the audio tracks and saves tooons of exporting time as I'm just hitting record and playing through the song once.
The issue arises when I'm trying to route the return tracks with reverbs and delays and stuff back through an audio track. It offsets based on the latency in the session. Which with all the plugins and my buffer set to 2048 can be half a second to a full second late. I'm not sure why these don't compensate for latency but audio tracks routed do.
If anyone can help me solve this it would be much appreciated! Thanks!
if anyone is going to ask why I don't bounce stems out normally, due to the use of external audio effect plugin in the mix session, each individual track will render in real time, one at a time. even if that track doesn't have an external effect. so for a big session on a 4 minute song it's super unrealistic to let it play through the song 60 times while I just sit and wait for it.
Latency compensation issue when routing return tracks through audio tracks
Re: Latency compensation issue when routing return tracks through audio tracks
Have you tried disabling the sends on the returned audio tracks?
Re: Latency compensation issue when routing return tracks through audio tracks
That seems to do it, thank you! I’ll get some more of them done and see for sure.
Re: Latency compensation issue when routing return tracks through audio tracks
It's covered in the manual somewhere but in brief: any audio stream that could be a feedback loop gets removed from the latency calculation/ auto offset .
The most common ones are having sends activated on return tracks. Even if these are set to 0 / -inf. There's a potential loop, and it would be theoretically impossible to calculate the latency of a looped audio path.
The other common one is routing return channels to a track (which has active sends). Which is a longer version of the above path, with the same issue.
In short it's intended behaviour, because the can't measure the length of a spiral.
The most common ones are having sends activated on return tracks. Even if these are set to 0 / -inf. There's a potential loop, and it would be theoretically impossible to calculate the latency of a looped audio path.
The other common one is routing return channels to a track (which has active sends). Which is a longer version of the above path, with the same issue.
In short it's intended behaviour, because the can't measure the length of a spiral.