Here I upload three screenshots of a Cubase project where I’m using the same plugins (quite heavy and cpu demanding plugins).
You can see the huge difference that makes using them in one single channel, like the master channel in this case, and using them spreaded throughout different channels.
As you can see from these screenshots, my i9 cpu is using only around the 10% of it’s resources while my cubase meter is reaching it’s maximum, not letting me to keep on working. This means the multihreading cpu management in cubase is far (really far) from being able to use the cpu power in a proper way and it forces us not to use intensive effect chains in serial since it will create a bottleneck. This forces the users to buy computers that are much more powerful and above the real needs.
I really wonder if this will be corrected someday.
(I know any of the steinberg staff will be answering in this forum, as usual).
Cubase and Nuendo have serious issues with cores and CPU resources management in “real-time” groups and masters. Its performance is even worse than Pro Tools. I’ve been requesting a new audio engine with better cpu management and dual buffer latencies such as Studio One or Logic, but it seems like nobody cares in Steinberg about this.
I agree, this is probably the most serious problem we have to face with this daw. I miss the old days where cpu performance was a mirror of my real performance. I remember upgrading my pc and there was actally a tremendous difference in real cubase usage. These were the early days of sx version.
I think that is more about your CPU speed. When you put all of the plugins on one track you are forcing your system to computer everything and line it up to go through all the plugins in series. That needs a very very fast CPU to achieve that kind of processing.
But because your CPU is not fast enough the ASIO guard is calculating the time delay that will be needed to allow the serial processing. But in this instant ASIO guard cannot add in enough time to match your buffer setting to make it work in simulated real time (ie real time after the ASIO guard delay).
It would not matter if the system uses 100% of one core or 20% of all cores or 100% of all cores, they are just not fast enough to churn out the answer in the time limit set by the buffer. So you need to increase the buffer or accept your not going to be able to add a load of plugins on the master bus like that, which seems like a none issue in the real world because no one is adding 20 plugins on their master bus or any one channel.
I was not adding all those plugins in the masterbus as a real project, (I think this is obvious), I’ve only done this for test purposes. Anyway, this is not too far from some real cases. There are times where my lead vocal buss gets fully charged with heavy plugins, and this vocal bus and the mixbus is where I’m getting serious problems when working and they force me not to play at my full potential, I can say I’m very limited by this a lot of the times.
As I said, I guess we, producers and engineers, must get our computers in a “brute force” way of thinking, knowing that we will leave a lot of % power unused only to be able to work in a proper way.
The question is how you can take your serial workload (one long chain of plugins) and make that parallel (?). Because the benefit of having a bunch of cores/threads is parallel processing. In other words if you have a compressor after an EQ then the EQ has to complete its task before the data is ready for the compressor. How do you make that parallel?
Users of other DAWs report the very same thing. I don’t think this is Cubase-specific.
I have the last intel i9 2,3Ghz macbook pro model, bought in 2020. I really thought getting the best laptop available in 2020 for these tasks would be enough to run cubase in a proper way in a demanding producing and mixing scenario (I’m not playing 500 tracks full of vst, I only make commercial music around 150 tracks).
Does this mean that a laptop is only able to run production tasks, and not mixing and mastering?
I’d like to know what you other guys are using, so I get it because I can’t allow this situation to harm my workflow this way.
It is perfectly obvious your doing that as a test, I am not saying your not. I’m just saying you could have a lot of plugins in a project, just not that many on the master bus. I didn’t mean to give that impression, but often we can create tests that do not really mean that much compared to an actual project. Your still going to get a log of plugins, just not like that.
You got a CPU with a speed of 2.3 ghz and whatever the boost is. The 2.3 Ghz is slow, very slow, so that’s not good. But the boost, if it’s always on, is a saving grace but in a laptop that can cause throttling.
I would not look at a 2.3 ghz laptop CPU and think I could have a lot of serial plugins. If your CPU was 6 ghz with C-state off then yes, maybe you could. But in a laptop it will throttle.
I’m not even sure an M1 Mac would do that well in that particular scenarios, even the new Ultra. I do have an M1 pro so let me know which plugins your using and your round trip latency I can test that out.
Or create a new example that gives the same results just using Fabfilters because I also have their plugins,
I have a long chain of plugin and compressor etc, bacially I filled up the master bus with heavy CPU plugins. M1 native C12.
One pic is at 2048 buffer and the worse one at 32.
So you can see even an M1 pro does similar, better, but similar. But it doesn’t matter because this is not going to happen on a real project.
On my machines I can have 35 virtual instruments (some rather heavy CPU synths), several FX channels and another 40 audio tracks all with 150 plugins across the channels and with 5 plugins on the master bus. At 2048 I can still play that project fine on my M1 pro.
So my point is the test doesn’t mean much because in any DAW your going to get the same issue. But it does not mean you cannot have a large project with more even distribution of plugins across all the tracks.
If you have a Vox and you really think you need 15 plugins on it then I would be thinking of other strategies to get around that. Version the track and rendering after any tuning or freeze the track and send it into a new buss for more processing plugins.
I guess what I am saying is, do not get hung up on that test because it’s not going to hold you back chap
FWIW I tried the recommendation of disabling Hyperthreading AND changing the system performance from “background services” to “programs” and I got around 10% difference on vst performance meter.
I’ve tried before disabling the HT option but there was no difference, so I suggest for anyone who wanna give it a try doing both.
@mlindeb Sorry, I did not notice that I’ve written that in the beta forum. Here is the original text:
That is unfortunately hard to improve since we cannot influence what happens within the plugin. Some plugins are spawning their own threads to process on multiple cores. From the engine developers perspective I would not recommend that since it destabilizes audio processing if done wrong.
But even within the plugin, calculations can’t be parallelized sometimes. Consider the following example:
(1 + 2) * 3 = 9
There is no way to calculate (3) * 3 = 9 before (1 + 2) has been calculated. It is not possible to calculate (1 + 2) on CPU core 1 while calculating (3) * 3 on CPU core 2 at the same time. You could do it, but you have to wait until core 1 has finished processing. Calculating it on 2 different cores would actually be slower since the result must be transferred from core 1 to core 2 before it could be used for further processing.
The same problem prevents parallelization if a plugin processes the output of another plugin. First applying a distortion to a signal and then an echo has a different result than the other way around or calculating both with the original signal and then mixing it together.
Not on cubase vst 3.5, vst 24, vst32, SX, all these versions matched my cubase performance meter with the task manager’s cpu performance. That was 25 years ago though
These threads are popping up every day. Mysteriously, some are disappearing completely.
It’s not a computer problem. It’s a Cubase problem, and it’s a very serious one.
This is not a Cubase problem per se, but a general thing, which is present on all DAWs or programs to some extent, which work with audio. As soon as you sum your channels to a Master or Mix buss with plugins on it, more load will be put on single core(s), as it becomes 1 connected audio path in the end.
This is why for DAW work, a good single core performance is needed.
You can reproduce this behaviour on every other DAW. Reaper e.g, seems to be more efficient in this regard though (at least on Windows). Wouldn’t have anything against reworking the engine to bring it to the efficiency of Reapers one.
Studio One dual engine allows have to have MORE plugins (measured by me) and you can monitor audio and instruments at the lowest latency while having the maximum for monitoring. That was implemented 15 years ago in Logic Audio first.
Pro Tools CPU use don’t suffer when you use plug-ins in busses. I have renounced to that and I only use channels, even for reverbs. Furthermore, you can freeze buses too.
Cubase is very sensitive to plug-ins and I never know if a big project will load again, I use to render and disable tracks all the time.
Bitwig can recover a crashing plug-in.
Piramyx keeps a core just for program stability, summing, etc.
