I’ve found that plugin delay compensation is not working at multiple buffer sizes / sample rates. Plugin delay is incorrect, is not sample accurate, thus null tests fail, parallel mixing results in comb filtering.
-make two identical tracks (with same source audio)
-flip phase of one track using mixer phase button
-put a plugin on one of the tracks
-set said plugin to DRY (so it just passes unprocessed audio but still goes thru the plugin buffer)
-listen… tracks should cancel out to silence
-try at different hardware buffer settings
-try at different sample rate settings
Of all buffer and sample rate variations I was able to find 7 combinations that failed this null test.
YES! Nuendo has always touted sample accuracy… unfortunately something went wrong and its been broken for a while. I know others that can also repro this.
This is a major issue for me as I ofter paralel mix. I would love an ETA on the fix?
My audio card won’t do all of those buffer settings and/or sample rates - my time in the day won’t allow it either
I tried the ones I could (you’re welcome) and your repro didn’t work.
Either provide more detailed instructions as to an EXACT repro (plug-in, audio hardware, OS configuration etc) or try a different audio card on your system (or another system altogether).
I checked 1024 buffer size and started with 44, then changed session to 96 (didn’t convert), then 176, 192, then 48. On 48k the issue was reproduced (only for the UAD plugin).
Not sure if this is a UAD bug or Nuendo bug only exhibited with UAD.
At least you should re-load your project.
Delay compensation is calcluated when the plugin is loaded; that is either when the project is loaded (with the plugins)or the plugin is loaded into the project. When switching sample rates the delay is not re-calculated and re-applied.
What crucial is, is that the project is closed before switching SR and re-opened after the SR was changed.
Any change of SR within an open project will -AFAIK-and I could be wrong- not result in a re-calculation of the latency.
Haven’t got the time to repro yet, will try tomorrow.
It’s hard to tell if it’s a bug. The procedure is that the plugin needs to report the latency to the host, then (and only then) the host applies (if needed) compensation for it. If the problem is confirmed, then it are the engineers who need to figure out if the latency is correctly communicated to the host and/or if the latency is correctly compensated for.
Also, be sure you have two identical tracks. If one track has -for example- an extra plugin with a higher latency, then that track will be compensated for the highest reported latency.
I seem to remember vaguely some delay compensation problems with UAD plugins, but that is a very long time ago.
And knowing UAD QA, it would surprise me very much if the problem would be on their side.
