What am I missing? I expected better.

[audiogamble]

Originally Posted by Raphaeld

Interesting, I didn't suspect this.

Also to note, the amount of latency any given plugin adds is fixed at different sample rates. This is built in by the plugin developers for various reasons.

Some plugins, like neutron or liquidsonics reverb for example, do have "low latency" or "zero latency" options in their settings. That is achieved either by taxing the computer's CPU more heavily, or by removing some high-powered processing within the plugin thereby changing the sound quality slightly. Again, these are on/off features of the plugins themselves, and do not auto-scale via detection of the host computer's processing capabilities.

So in conclusion, you just need to get to know which plugins add latency and which do not. And when that is / isn't a problem.

[Raphaeld]

SOLVED

So, in the spirit of helping another member who may see this I have solved the problem, for now. Like with most problems, there were a number of factors.

First the results
o no delay, nothing even amber
o I have my playback engine at 128 samples and cache size at "normal." (4TB SSD)
o My CPU runs at 52% for the complete song (I have a Mac Studio Ultra)
o UAD DSP @ 48% (have have an x4 and two satellites)


In no order in particular here is what changed to fix it and take advantage of my system:
o I switched from using one instance of Opus and 7 channels to 11 instances of Opus on 11 different instrument tracks. Once instance/track.

FYI-I have all my busses (i.e. drum bus, guitars bus, etc.) going to aux sends called, for example, MX_DMS, MX_BG, MX_GTRs, MX_LVOX, etc. This makes it easy for me to do automation on the bus faders while still letting me quickly tweak the MX_nn faders. All the MX_nn auxes goes to an aux called MX_MIX and then out. This lets me raise and lower the entire mix easily and also is useful for automation like raising the overall volume for the chorus.

o I had my non-vocals reverb send channeled to the above MX_MIX aux which was also getting all the MX_nn auxes as well. Basically, I had a lot of channels going to MX_MIX. Obviously, PT couldn't keep up. I created a new aux MX_FX and sent MX_FX to MX_MIX and that removed all red delay.

o I had only one Neutron 4 instance on MX_LVOX. I removed it and that made a difference. I'm sorry, I like Neutron.

o I like to use UA plugins. Even though I have a lot of DSP I decided, anytime I have a choice, I'll use the Spark version so it'll use the computer's powerful CPU and, even though minimal, there's no need to run out to my satellites and back. Also, I suspect my CPU is much faster than the ones in the satellites.

o Lastly, for some reason, the xUAD SSL Bus Compressor was causing a lot of delays. I had one on each of the seven MX_xx auxes. I replaced them all with the xUAD API 2500 and green all around.

This experience, while frustrating at times, really helped me improve my template which let's me work in PT the way that works well for me and, so far, let's me take advantage of my new gear. The major lesson learned was, while plugins are always the usual suspects for good reason, your routing can cause delays too.

[indeloon85]

Originally Posted by Raphaeld

SOLVED

o Lastly, for some reason, the xUAD SSL Bus Compressor was causing a lot of delays. I had one on each of the seven MX_xx auxes. I replaced them all with the xUAD API 2500 and green all around.

Side Question - the mention of an 'xUAD SSL Bus Compressor' makes me think they've released a spark/native version of this plugin (Like the mentioned xUAD API 2500). Is that true?

[Raphaeld]

Originally Posted by indeloon85

Side Question - the mention of an 'xUAD SSL Bus Compressor' makes me think they've released a spark/native version of this plugin (Like the mentioned xUAD API 2500). Is that true?

Good catch! That helps me, the SSL Bus Compressor was the DSP version and removing it improved the speed so that aligns with my theory. I went from the DSP SSL to the non-DSP API and saw the red disappear immediately on each bus.