A few questions about Studio One 7 + Mac Studio M2 Ultra on MacOS Sequoia.

[MC2]

This is my first post on the forum, so I wanted to say hello and ask a question right away .

I have a new set of Mac Studio M2 Ultra with macOS Sequoia and Studio One 7 on board + Presonus Studio 1824c.
I have a performance problem. I'm running a multi-instrument 3x piano ( Arturia Augment Grand Piano, Spitfire BBC Symphony Orchestra Pro Piano, Numa Player.) on one test track to that for each instrument EQ + compressor (TC Electronic PEQ 3000 and DYN 3000). For the master limiter (TC Electronic Brickwall HD and TC Electronic Master X HD).
When nothing is played CPU performance is at 14-30% However, just when I turn on track playback CPU load increases to 100% and more.
Currently I have Device Block Size set to 128 samples. And managed to master the audio clipping.
and “Enable Plug-in Nap” are enabled. “Enable low latency monitoring for instruments” and ‘use native low latency monitoring...’.
I don't quite know how to set the parameters to allow more VST instruments to be handled.
I also noticed that when low latency monitoring for instruments is enabled, the space shrinkage disappears somewhere. The piano sound is much closer - no depth. So which configuration is correct?
The question is what should I pay attention to for proper configuration? Maybe I should change the system to Ventura? Because from the tests I watched on YT, it seems that the hardware should handle much more than what I did in the test.
Something you will advise to be able to work normally on this equipment?

M.C.

 

[js1]

Your M2 Ultra is a beefy machine, so I wouldn't expect you to be at 100% with 1 test track, even with 3 instruments on it.

Plug in napping essentially disables the plugin if no audio is going through it. When you are not in play/rec, or if there is no audio event for a track playing back, the plugin is disabled. This is likely why the CPU performance is low when in stop.

When you say "hits 100%", is it pinning at 100%, or does it spike to 100%? I'm suspecting the latter. If you increase Device Block Size to 1024 or more, does it settle down to a lower level?

 

[MC2]

It gets better. After increasing the buffer to 512 samples (more is not possible), the possibility of affecting the monitoring of latency, whether native or instruments, disappears. The load has dropped a bit. It is currently at 90% during playback. In live playback, you start to hear a minimal delay between pressing a key and the sound appearing.

 

[Jemusic]

I have got an M2 Max and even without Ultra I am not seeing anywhere this amount of CPU use. I am on Sonoma though. Did you upgrade to Sqeuoia because I am not sure how it is with Audio and music yet. Its pretty new. Its best to stay one ot two OS systems back from the current Apple OS system.

Try disabling the low latency monitoring and just try and play the instruments live with a lowish buffer and see how that works out.

 

[Crossinger]

Did you upgrade to Sqeuoia because I am not sure how it is with Audio and music yet. Its pretty new. Its best to stay one ot two OS systems back from the current Apple OS system.

Staying one system version behind should be sufficient. Good advice! But if you need to buy a new Mac (with non-downgradable system), you're lost.

 

[MC2]

After launching Studio One 7, I set the buffer to 1024 samples and disable the latency control completely. After opening the session and re-entering the settings, I already have a buffer of 512 samples and I can't set a larger one.
In the Processing tab, I only have an effect on Enable Plug-in Nap (enabled).
On the other hand, in the monitoring latencies section I see that in the standard column it is 156ms/7504 samples for audio and 59ms/2850samples for instruments, while in the Low Lancy column it is with audio -0 and blue Z, with instrument N/A .
On the CPU performance indicator I can see a significant improvement - it occasionally hits the orange box (when a lot of midi messages are generated live)
When playing live, it feels a bit of a lag between the key press and the appearance of the sound. But this is already much closer to an acceptable level.

Staying one system version behind should be sufficient. Good advice! But if you need to buy a new Mac (with non-downgradable system), you're lost.

I currently have macOS Sequoia originally installed, but it is possible downgrade to macOS Ventura and lower supporting Apple Silicon processors. The good thing is that you can download earlier versions of the operating system compatible with your machine at no extra charge. However, as long as this is not necessary I want to avoid it - too much work with reconfiguring the whole thing

 

[Crossinger]

I currently have macOS Sequoia originally installed, but it is possible downgrade to macOS Ventura and lower supporting Apple Silicon processors. The good thing is that you can download earlier versions of the operating system compatible with your machine at no extra charge. However, as long as this is not necessary I want to avoid it - too much work with reconfiguring the whole thing

Oh, that would be new to me. In the past Apple did lock any downgrades. Rule: minimum version that runs on a machine is the shipped version of the OS. Because older macOS setups don‘t contain necessary drivers for the newer hardware. Maybe you can use patch tools to create a Frankenstein version with older OS and newer drivers, but this is neither fun, nor stable.

 

[MC2]

Oh, that would be new to me. In the past Apple did lock any downgrades. Rule: minimum version that runs on a machine is the shipped version of the OS. Because older macOS setups don‘t contain necessary drivers for the newer hardware. Maybe you can use patch tools to create a Frankenstein version with older OS and newer drivers, but this is neither fun, nor stable.

That's why I wrote about the fact that you can do a downgrade only within the framework of systems that support a particular processor. In this case, the M2 Ultra, that is, below macOS Ventura is unlikely to go down.

 

[LiveFromPFD]

Congrats on your M2!

If you bring up the Performance Monitor and sort by latency and CPU, what plugins rank the highest?

Everything works perfectly for me on Studio One 6 and Sonoma, running 32 or 64 block size. I use Mai Tai and Analog Lab V for synths. I don't use plugin nap or low latency on my master.

If I take the same session and open in Studio One 7 my CPU goes nuts, and I can barely get things to play at 512 or 1024 block size.

 

[js1]

OK, next step. Go back to your audio setup preferences, and click on the processing tab. Set dropout protection to Maximum. UNCHECK Enable low latency monitoring for instruments (i.e. turn it off). Is your playback solid now? What's your performance at?

Your instrument record latency will be horrible. But if things are solid on playback, we'll deal with that next.

 

[Jemusic]

If I take the same session and open in Studio One 7 my CPU goes nuts, and I can barely get things to play at 512 or 1024 block size.

This is weird. Any large V6 sessions actually run slightly better for me eg less CPU on V7. I am nowhere near the limit of the computer either.

 

[MC2]

If you bring up the Performance Monitor and sort by latency and CPU, what plugins rank the highest?

The highest latency is introduced by the Master X HD 10ms plug-in and then each of the EQs at 1.3ms.
The highest load on the CPU is generated by a multi-instrument and in it the BBC Symphony Orchestra 2.

 

[MC2]

OK, next step. Go back to your audio setup preferences, and click on the processing tab. Set dropout protection to Maximum. UNCHECK Enable low latency monitoring for instruments (i.e. turn it off). Is your playback solid now? What's your performance at?

Your instrument record latency will be horrible. But if things are solid on playback, we'll deal with that next.

Interesting thing about this setting Device Block Size, or the Preferences tab in general.
When I set the parameters in the main program window, values as high as 4096 samples are available for Device Block Size. However, when I call up the same tab from an open session a maximum of 512 samples is already available. The same is true for Dropout protection. In the preferences set directly, the Maximum parameter is available. However, already in the session max Medium is available and 512 samples in DBS. After disabling latency monitoring for instruments and native latency monitoring, noticeable latency increased when playing live.

I found....the cause of the limitations. I created a brand new simplest session. And here all parameters are available in high values. The original session was in Atmos and this condition imposed a limitation to DBS 512 samples and dropout protection on Medium.
I went back to the original session only with Atmos switched to Surround. All parameters are available.
After disabling the latency control, the latency in playing live increased significantly - it is actually impossible to play anything faster in tempo. In the Monitoring latencies section next to Audio Roundtrip, a blue Z (Hardware Monitoring Available) checkmark appeared. The CPU load dropped to a maximum of 60%

 

[Wolfger]

Is your Multi-instrument track record-armed or in monitor-mode when playing back?
I ask this, because tracks in "live-mode" process all their instruments and plugins all through to the master-bus on one core when in low latency mode.
So even when having a M2 Ultra with lots of cores and power, the limit is the single core.
I just checked this on my M3 max with Arturia Piano, Stage 73 and Pigments in a Multi-Instrument, with some plugins on each instrument channel and on the master-bus like in your description and got the same results. This is the limit of the system. There always will be a trade-off between low- and high buffer settings and playability regarding latency on the one hand and cpu-use on the other.

 

[MC2]

In fact, turning off record-armed on the track resulted in a 20% drop in CPU load - sensational.
On the other hand, I also noticed that dropping the multi-instrument circuit and simply duplicating the midi tracks with transferring the EQ and compressors to them, respectively, lowered the CPU load by another 20% and now the entire session loads only at times 43%.
That is, it is already much better. I tweaked the parameters and now with 3 identical tracks + the same set of plug-ins (EQ+ compressor) only with different instruments I have:
Dropout Protection : Maximum
Low latency monitoring for instruments
Native monitoring
DBS 128 samples
Spatial audio - Surround
REC and Monitor disabled
Result:
- 7-11% CPU at rest
- CPU playback max 43%

Same set as Multi-instrument:
- at rest CPU 11 - 15%
- CPU playback 60-74%

Same only in Atmos:
Multi-instrument:
- at rest: 17%
- playback: 65-80%

3 separate tracks:
Requires Nap on, otherwise occasionally compressor plug-ins hang (crash)
- at rest CPU 11%
- playback CPU max 43%

Conclusions that emerge:
The biggest impact on CPU load is... playing live ( record-armed enabled).
If we turn it on multi-instrument then I guess we have record-armed running for each component instrument.
If these are wrong or questionable conclusions then let's discuss
Is it possible to improve the parameters even more?

 

[Wolfger]

Those are the right conclusions! Except I would rephrase to " The biggest impact on single-core CPU load is......."

The CPU meter of Studio One is always showing the CPU load of the single most loaded core.
So with record-arming a CPU intensive instrument running through a lot of processor-intensive plugins even on the master-bus will give a overload, even when all your other cores aren´t used at all.
It´s not really possible to improve those settings, except raising the buffer to numbers that still allow for distract free live-playing when recording. but those are very personal.

 

[Jemusic]

Don't forget you can see what all your cores are doing. Mac has got Activity Monitor app built in. Go to
Applications/Utilities/Activity Monitor

When this opens up check out the CPU graph down the bottom. Double click on the actual graph that is being displayed and the display for all your cores will show up. Efficiency and Performance cores are all identified. You can see what is going on under various conditions.

 

[js1]

Busy day today, so only a shortish, probably not perfectly clear reply now. I'll do better later (so, please don't bust my chops just yet!). Yes, it may be possible to lower your CPU when record enabled, but it's tricky.

Presonus overshot when they did their low latency monitoring. Other DAWs will disable long latency plugins in the audio path of record channel. This, of course, changes the sound when recording, not just on the record track but on all tracks sharing that audio path. Presonus, on the other hand, will, as much as possible, try to keep the sound the same. Sometimes, plugins still will be disabled, but less often than you'll see on some other DAWs.

S1 creates a separate audio path with short latency for the track you're recording. The playback tracks will still have all the latency of all the other plugins, but they'll compensate for that during playback. If your audio path is sharing plugins (because of busses or on the main out), it will ADD plugin instances when green Z is enabled, and you've got your track in record monitor. This is why CPU load goes up.

So, to start, don't load up your main outs with high load mastering plugins while recording. As long as they are low latency plugins, S1 will add another set to your record audio path. There's more... but later.

 

[MC2]

Presonus overshot when they did their low latency monitoring. Other DAWs will disable long latency plugins in the audio path of record channel. This, of course, changes the sound when recording, not just on the record track but on all tracks sharing that audio path. Presonus, on the other hand, will, as much as possible, try to keep the sound the same. Sometimes, plugins still will be disabled, but less often than you'll see on some other DAWs.

S1 creates a separate audio path with short latency for the track you're recording. The playback tracks will still have all the latency of all the other plugins, but they'll compensate for that during playback. If your audio path is sharing plugins (because of busses or on the main out), it will ADD plugin instances when green Z is enabled, and you've got your track in record monitor. This is why CPU load goes up.

So, to start, don't load up your main outs with high load mastering plugins while recording. As long as they are low latency plugins, S1 will add another set to your record audio path. There's more... but later.

OK, so now I understand why in some situations, despite the addition of only one instance of a particular plug-in, another instance appears in the performance indicator.
That is, when catching up more tracks, it is better to put the plug-ins to be added to the recording for that time in this particular channel than in the total? Well, and in general separate the use of plug-ins for recording at the time of recording and the use of plug-ins for mastering as we are no longer catching up on anything.
General I can see that this is so a bit of an art of compromise. Because, however, sometimes there is a need to record with specific sound “changers”, and adding them only at playback can significantly hinder the recording itself (for example, a specific long reverb)

 

[js1]

I was going to provide a strategy that had worked for me in the past (on the PC), but I saw something a few days ago that I have to go back and verify, lest I mislead you. I'm hoping to do a deep dive later in the week.

One safe thing you can do is come up with a set of low CPU plugins that provide the effects, but may not be as polished as the final one on the mix. Per your example, for a long reverb you have a lot of options that will be low CPU for recording. Not optimal, I agree, but as long as the one you choose leads you to make the same decisions and performance as the heavy duty option, it can work.