IDM Superstar wrote:Again, take a kick drum, like an 808. FX rack it, one path has EQ8 set, the other empty.
Click EQ8 off and on while playing back your kick drum.
I did exactly this, and it works 100% like it should
IDM Superstar wrote:Take a kick drum that goes THUMP, split it in two. On one side add EQ8, don't even bother changing any parameters. Leave the other empty, listen to the output.
Click EQ8 on and off to hear the difference. If you don't hear your THUMP turning into a bit more of a DONK then congratulations, you're not a producer.
Guenon wrote:Just tested this. Took a clip, slapped on a rack with one empty chain and one chain with an EQ8. The output is identical with the EQ8 on and off.
I don't hear the difference because there isn't any.
Quick note: all ableton "hiQ" devices (and the overdrive) have uncompensated delay in order to oversample. Any LPF parallel phase cancellation effect is due to that offset.
#2 PDC is inactive on return channels with their own send activated.
pedx1ng wrote:EQ8 should be in High Quality mode to show the issue. There is some uncompensated delay in HiQ mode.
Guenon wrote:pedx1ng wrote:EQ8 should be in High Quality mode to show the issue. There is some uncompensated delay in HiQ mode.
Ah, thanks for this addition. Yes, I tried it and it does misbehave when in high quality mode. In an actual layering scenario, a quick fix would require inserting a neutral instance of the same plugin into the other rack chain as well, to keep the chains in sync - hardly an elegant solution to the underlying problem, though, especially when doing more elaborate layering.
andy_cytomic wrote:I'm glad I'm not the only one that worries about sample accuracy!
A much better solution is to run your entire project at 88.2 khz or 96 khz, then you don't need to oversample in individual plugins, and all your EQ shapes are very analog like in shape and phase, and your aliasing is reduced across the board so all your mixes are clearer and tighter. If the oversampling can be bypassed in your plugins (which I allow in mine by not all developers support) then there is no extra latency introduced so nothing needs correcting for. The cost here is increased CPU usage across the board as well, with every single plugin taking twice as much cpu.
dusted william wrote:hey Andy,
Thanks for the awesome post.
Would we get same benefit is we choose oversampling on individual plugs in render modes, but still worked in 44.1?
dusted william wrote:Is there a DAW that you know of that doesn't have this problem?
looks like I'm going back to running things in 96 khz
coroknight wrote:Unless you are making really simple music these issues are going to become more and more of a problem.
andy_cytomic wrote:There is a solution, and that is to use linear phase FIR oversampling filters. Ok so what's the tradeoff for this fix? Slightly more cpu usage and more latency, but this time the latency is constant and can be corrected for by the phase so the crack of your transients all stay put and don't turn into limp plops when they phase with other parts of your track.
andy_cytomic wrote:So the formula is:
song position and automation advance in samples = (number of 3rd party plugins on track before the one that needs sample accurate song pos and automation) * (audio card buffer length)
and if there is extra latency introduced by linear phase oversampling then the formula is:
song position and automation advance in samples = (number of 3rd party plugins on track before the one that needs sample accurate song pos and automation) * (audio card buffer length) + (latency of all 3rd party plugins on the track before the one that needs sample accurate song pos / automation)