Studio One VST performance - still an issue?

[chk071]

Don't want to open the can of worms, TBH, but... after a long time, i installed Cubase 9 Artist again yesterday, on my desktop, and my laptop, and, i was quite stunned that, at least on the performance meter in the DAW, Cubase took about 50% of the CPU Studio One was taking, for the same VSTi's. Also, Studio One already began to crackle with some more expensive patches, with my onboard audio/sound card, while Cubase didn't even get into the crackling regions. Of course, totally unscientific test, i know it's better to use the task manager, or something similar. Just wondering, did anyone notice the same? I thought, since Studio One 3.5, the performance issues it had were more or less a thing of the past. Was quite an eye opener, TBH. IF that first impression was right.

[ATS]

I just tested Cypher 2 with the same patch in Acid Pro 8 and Studio One 4 and both cpu use was the same.

[Jim Roseberry]

At version 3.5, Presonus implemented "Hybrid Buffering" in Studio One... which greatly increased performance.

Tracks that are merely playing back are processed using a large buffer size (much more CPU efficient).
Tracks that need to be monitored in realtime are processed using a small buffer size (low round-trip latency).

FWIW, When pushing heavy loads at a 32-sample ASIO buffer size, I find Studio One v4 a lot more CPU efficient than Cubase 9.5.

If you're composing and need features like Note-Expression/etc, you really don't have much of a choice.
Use the fastest CPU you can... and learn to work within Cubase 9.5's performance confines.

For Cubase 10, I hope Steinberg improves CPU performance.
Introducing "Hybrid-Buffering" would certainly help.

[Funkybot's Evil Twin]

I alternate regularly between Studio One and Cubase, and I think Cubase still performs better at lower latency. I get fewer clicks and pops with very low buffer sizes in Cubase. I think Cubase's ASIO Guard does something similar to Studio One's dual-buffer approach, but just works better in practice.

Studio One's dual buffer design is a mixed bag IMO. It can actually be very CPU intensive when you enable input monitoring as it doubles up on the effects to create two monitoring paths, but when input monitoring is off and you're just mixing, it's actually helped with CPU usage. Another downside of it's design is that if you have Low Latency Monitoring enabled and a plugin in the monitoring path doesn't have VST automation parameters pre-assigned (like Amplitube), any changes you make to the plugins parameters won't be reflected in the monitored audio path until you toggle the Green Z off and back on. So great when mixing, not so great when tracking IMO (due to CPU issues and plugin incompatibilities).

When it comes to sheer input monitoring+low-latency efficiency, my anecdotal experience indicates Cubase outperforms Studio One. When it comes to mixing, I'm not so sure, Studio One could have the edge there.

[chk071]

Thanks for the replies. I just did a better test, on Windows 10 64-bit (forgot to add that info), with high performance energy setting, and with my UR22 audio interface, and, they both performed about the same with a pretty moderate 3 osc 9x unison each Spire pad. Actually, in the task manager, both Cubase and Studio One took about 3,5 - 4,5 % CPU on that patch (both DAW's take about 0,5 - 1,5 % while Idling/no plugin loaded), which is pretty great. Note to self: Forget the DAW internal performance meters.

[Jim Roseberry]

Try running Helix Native at 96k with a 32-sample ASIO buffer size (1ms total round-trip latency).
That's equal to the fastest top-tier modelers (besting most).

Using a well-configured i7-8086k based machine (all six cores locked at 5GHz) and Quantum audio interface: CPU use in Studio One v4 is high (43-47% depending on the complexity of the patch)... but audio is completely clean
ASIO spikes in Cubase 9.5 cause audible glitches

Having to uncheck/recheck the Green "Z" button (in Studio One) every time you make a change in Helix Native is slightly annoying... but the performance is (IMO) worth the trade-off.

Helix Native running with the Quantum sounds very good... but that's another subject.

[antic604]

Note to self: Forget the DAW internal performance meters.

Well, no. At the least take it with a grain of salt, but actually internal meters are more accurate in showing available DSP headroom, which is not only related to CPU, but also memory bandwidth, HDD, etc. You can exhaust your system DSP resources at 50% CPU usage in certain cases.

Also, running a test with single instance of VST can be very misleading, as this doesn't take into account multi-core/thread performance, which is tricky to pull off. So if you want to make a test, duplicate a track with some heavy VST (or chain of VSTs) several times until it starts crackling and compare the results (number of duplicates).

[Jim Roseberry]

In the case I mention above running Helix Native, multiple CPU cores were being used (confirmed using Task Manager's Resource Monitor).
It wasn't just hitting one CPU core hard... the load was spread fairly equal across all six cores (12 processing threads).

[antic604]

In the case I mention above running Helix Native, multiple CPU cores were being used (confirmed using Task Manager's Resource Monitor).
It wasn't just hitting one CPU core hard... the load was spread fairly equal across all six cores (12 processing threads).

That's different - it was the VST spreading its load into multiple jobs, but not all (minority, actually) of VSTs are doing it. Therefore it makes sense to test performance with multi-track projects, because typically one track = one core/thread, unless specific VSTs allow for more fine-grained allocation of their workload.

TLDR: using Helix you've tested this VSTs mutli-core/thread performance, not DAW's

[Jim Roseberry]

In the case I mention above running Helix Native, multiple CPU cores were being used (confirmed using Task Manager's Resource Monitor).
It wasn't just hitting one CPU core hard... the load was spread fairly equal across all six cores (12 processing threads).

That's different - it was the VST spreading its load into multiple jobs, but not all (minority, actually) of VSTs are doing it. Therefore it makes sense to test performance with multi-track projects, because typically one track = one core/thread, unless specific VSTs allow for more fine-grained allocation of their workload.

TLDR: using Helix you've tested this VSTs mutli-core/thread performance, not DAW's

While I'm certainly aware of your point (and don't disagree), my underlying point is that Cubase 9.5 can not do the same (run Helix Native sans glitches at those settings).

Pushing heavy loads at super low round-trip latency is not Cubase 9.5's forte'.
It would be nice to see Cubase 10 with improved CPU efficiency.

If the muse strikes (and you play guitar/bass), it's pretty cool to be able to just plug-in (to a decent Hi-Z DI), call up anything from a decent acoustic simulation... to Fender clean... to Marshall crunch... to Friedman BE-100 higher-gain. All sounding very good... with super tight timing/response.

I've owned all the top-tier modelers (including the Axe-FX III).
Compared most side-by-side.
Playing thru the Presonus Quantum, the sound of Helix Native is the best I've heard from any AmpSim plugin. Can easily hang with Helix Hardware and any of the other top-tier guitar processors.
If you've got a world-class DI (Neve, etc), the sound can be even better.
To me, the ability to play thru AmpSim plugins at 96k with total round-trip latency of 1ms; with quality that equals (in some ways bests) the best hardware guitar processors is somewhat exciting.