Post
by Angstrom » Tue Sep 18, 2018 1:52 pm
Nah.
read again:
FIRST : plugins on the master will always introduce latency on all DAWs. For example: tracks 1,2,3,4 ... fed into a plugin on the master bus such as a compressor which has a latency of 15ms. In this case tracks 1,2,3,4 will now be fed through that 15 ms of latency + whatever hardware latency your system has. Tracks 1,2,3,4 fed through a bus track "My bass buss" with a mastering compressor on it with 15 ms of latency ... all those tracks 1,2,3,4 will have that 15 ms of latency. This is also the same on all DAWs, it is not possible to be any other way.
SECOND Live is a live-stage capable application, so while other DAWs will take a deactivated plugin out of the latency calculation when they are deactivated Live does not. when plugins on the master are deactivated it does not recalculate the latency of the audio streams and re-sync them with the new plugin delay calculation - because on stage that would make a big POP noise through the PA. So, Live does not do that. It aims to maintain glitch-free audio. Deactivated plugins are still used to calculate the offset of all tracks fed through them .
THIRD there is no way physically, computationally or magically for any DAW to avoid the processing and calculation time that a plugin uses if the stream passes through that process. If it takes 15 ms to calculate the output of a convolution process then that's what it takes. If a signal passes through this process then it will incur the inherent delay.
The only way to avoid that delay in any DAW is to route a monitored signal direct to your hardware outs and bypass whatever bus processing you are using which incurs the delay. You are free to do this, a lot of people do, but now your audio-processed and latent signals will be out of time with your bypassed signals. This is how all DAWs work, it is how computers work, and how processing works.
FOURTH Live does provide a "fastest path " method, which will ignore other sibling tracks latency, but it cannot ignore the latency of the channel it is passing through. So if Track 1 has 10 ms latency, and 2 has 200ms latency - and the master has 20 ms latency . If we activate "reduced latency when monitoring" track one will now have 30 ms latency and track 2 will have 220 ms latency. They will be getting to the outputs at the detriment of track sync, track one will get to the hardware quicker than track 2 --- but it must still pay all tolls it passes through.
FIFTH
your "major disappointment " and mentions of "don't master on the master bus". You arent mixing, you are tracking. When you set up to track, do it correctly,
Check again what you are doing. Make sure your audio hardware is at around a buffer of 128, set your audio device sample rate to 88 or 96kHz . Ensure that "reduced latency when monitoring" is active, ensure that any plugins on the master out have an absolute maximum of 10 ms latency.
LASTLY It's not about "don't master on the master bus". I have a bunch of plugins on my master bus when playing live. The thing is - I make sure they have a very short latency. This can be seen by hovering over them in Live's device view. Look at the info view bottom right for the latency of each plugin.
EXAMPLE OF A SETUP
This is for live performance, with plugins on the master. My output latency of my audio device - An RME Fireface at 88kHz is 3.2 ms of output hardware latency
With Glue and Saturator on the master I have a (Live induced Master channel) additional latency of 0.41ms
that gives me a total output latency with plugins on the master of 3.61 ms
set a delay to 4ms and see how short a delay this is, it's very very small.
Nice try! 