What am I missing? I expected better.

[Raphaeld]

There MUST be a variable I’m not considering so please help me out.

I thought my new setup was so powerful I wouldn’t have any red track compensation indicators? Why do I still do?

1) I have a brand new MacStudio Ultra with 128GB of memory, 16 cores and 3.37TB available on my internal SSD.
2) I’m using ProTools Studio 2022.5.
3) I have an apollo x4 with TWO quad satellites.
4) My system usage is at 18%
5) My disk cache is at 29%, memory at 8%
6) My UAD DSP is at 33%
7) Delay compensation is ON

In my estimation my system should be more than adequate for what I’m doing. My whole session is about 40 tracks including folders, sends, etc. I am using two virtual instruments: SD3 and East West Opus who’s samples are on a external SSD.

I have two instances of Opus, one with one channel and the other with 7 channels. When I freeze Opus with 7 channels the delay for that instrument goes away. I didn’t experiment with using 7 instances of Opus, maybe I should.

SD3 doesn’t cause any delays.

I also had a few channels of Neutron 4 which I had to freeze because it was causing more of a delay PT could compensate for (red indicator). I know iZotope is notorious for requiring a lot of head room but man, I have headroom to spare!

I also have a few Melodyne tracks with 9 plugins. Some are amber but none of them are causing any red track compensation indicators.

When I upgraded from my 2018 MacMini I thought this new setup was so powerful I wouldn’t have to spend my time freezing and unfreezing tracks and I could just work. But I’m back to the freeze/unfreeze workflow and I’m completely at a loss. The only other factor I can think of is Rosetta vs. a fully native ProTools (wishing and hoping).

[daeron80]

That's quite a system! Should keep you from needing a separate tower for VSL for some years.

Counterintuitively, latency is not directly related to computer power. If a plugin causes 100 samples of latency on any system, it will cause 100 samples on all systems. At least, so I understand it. And have always found it to be true.

One thing it should make a difference to is offline bounce times. And I bet there's not a VI out there that would cause crackles or CPU spikes due to lack of power.

[audiogamble]

There's a limit to how many samples any given PT track can compensate. This is a limitation of the software. That delay limit doesn't scale with computer power, so sadly all PT users on all systems need to work within this.

[Raphaeld]

I would **assume** (hope, wish) when a M1 native version of PT is release it should increase it’s ability to compensate.

[Sardi]

Originally Posted by Raphaeld

I would **assume** (hope, wish) when a M1 native version of PT is release it should increase it’s ability to compensate.

Your assumption is wrong.

The latency induced by the plugin will always be the same. It has nothing to do with the DAW. It is how the plugin is coded.

As pointed out, the only limitation Pro Tools is applying is the max amount of samples it will compensate for. But even if it’s under the limit, the delay compensation engine is only putting all your tracks in sync on playback. It’s never going to fix tracking latency.


Sent from my iPhone using Tapatalk

[Darryl Ramm]

Originally Posted by Raphaeld

I would **assume** (hope, wish) when a M1 native version of PT is release it should increase it’s ability to compensate.

Why would you assume that? Changes might cause compatibility issues with HDX and hybrid engine, so I would have little expectation of this changing.

Not sure how you got so confused about all this, the latency you are seeing in Neutron is caused by the heavy look ahead algorithms in some modules, those algorithms unavoidably insert delay. You can turn on zero latency mode if really needed to stop them using lookahead, or just reserve those modules for use on the output/master fader. I expect all this is discussed in the documentation for Neutron. I guess I am lost on the whole premise of Neutron, the whole idea of adding a mix engine inside a mix engine (your DAW) just seems like a layer of cruft to me. Including if you want heavy look ahead limiters etc. there are so many nice ones out there already including from UAD.

[Rich Breen]

CPU power doesn't really affect latency directly - that's up to the plug-in manufacturer, but there are some tweaks: Buffer settings will affect plug-in latency, so make your buffers as small as you can. Some plugs (Liquidsonics for example) have the ability to trade off CPU usage for latency; if those plugs are set for "Low CPU Usage" they'll have high latency - if the plugs you're using have the option you should set them for highest CPU usage / lowest latency. Lastly, pay attention to if you're stacking multiple high latency plugs on single tracks or in the entire path.

[nednednerb]

Originally Posted by Darryl Ramm

I guess I am lost on the whole premise of Neutron, the whole idea of adding a mix engine inside a mix engine (your DAW) just seems like a layer of cruft to me.

This is off-topic, but Neutron modules can be individually used in RX module chains, which is useful for those using RX a lot. Also, in PT I never use Neutron mix engine plug-in. I only ever use the individual plug-ins. So I get the familiarity of the iZotope UI across plug-ins, and am definitely not running the engine inside an engine. I agree with that sentiment but can point out it doesn't strictly apply to all uses of PT and Neutron.

As far as latency control, I dream of the computer using itself more efficiently and not encountering these bottlenecks. I think it is conceivable for future processor capacity to ONE DAY be unlocked by audio developers.

A silicon native PT is one little step toward that, but backward compatibility is far more important to professionals right now than being experimental when it is not necessary for a great proportion of daily work. On the other hand, stability is one of the most necessary things!

Sent from my Pixel 6 Pro using Tapatalk

[Darryl Ramm]

Originally Posted by nednednerb

This is off-topic, but Neutron modules can be individually used in RX module chains, which is useful for those using RX a lot. Also, in PT I never use Neutron mix engine plug-in. I only ever use the individual plug-ins. So I get the familiarity of the iZotope UI across plug-ins, and am definitely not running the engine inside an engine. I agree with that sentiment but can point out it doesn't strictly apply to all uses of PT and Neutron.

That's a good point, and I sure think iZotope makes some great stuff and RX is amazing. But if the OP is laying Neutron mixer into mixes, they may want to slow down, understand what's going on more, and sure pull stuff out and play with it stand alone. It also just sounds like maybe a lot of stuff going on, lots of UAD DSP, heavily stacked Melodyne, Neutron etc. At some point you want to step back and ask is it worth it. And with so much UAD DSP there, their limiter plugins (if that's what is causing the latency in Neutron) would probably be the ones I reached for first.. and make a decision they live on the master fader or if a special reason on another bus or track and I'd deal with the latency consequence of that deliberate choice. And yes that's paritaly use bias, but UAD did those limiter plugins well (as have many others... depends what exactly you want... I hope Neutron does not drive itself to crudely push up "loudness" in the mix with all these heavy limiters).

[midnightrambler]

Sidenote - don't really know why Melodyne should be adding *any* latency, mine always run at 0ms.