Hi UniAmoog,
I’m pretty shure it’s only a meter bug thing. I don’t see real performance issues.
I have this meter problem on 3 machines, Win11 laptop, Studio PC and a Mac Mini. So since all machines with totally different OS and setups have exactly the same issue with cubase and Nuendo. It can’t be machine setup related.
But since I can’t see reel performance issues I don’t care anymore.
When Ableton Live changed their metering in 11, folks were freaking out left and right. Ableton’s answer was simply: ‘If the project is playing fine, don’t worry about the meter’.
To avoid the illusion that the meter is bugged - I ran the test from the link above again. So we duplicate Retrologue 2 until the sound starts to have drops/crackles and we don’t look at the meter.
Windows 11 and its optimization are not the problem. Cubase 11 behaves very similarly (but still a bit worse). However, C13 and C14 (it’s even worse) are much less efficient, so the meter is not wrong ![]()
Either I have something set up wrong or Steinberg is regressing in development:
Windows 10
Cubase 11
Buffer size 1024, 141 instances
Buffer size 128, 130 instances
Buffer size 32, 127 instances
Windows 11
Cubase 11
Buffer size 1024, 140 instances
Buffer size 128, 127 instances
Buffer size 32, 120 instances
Cubase 13
Buffer size 1024, 133 instances
Buffer size 128, 122 instances
Buffer size 32, 119 instances
Cubase 14
Buffer size 1024, 132 instances
Buffer size 128, 121 instances
Buffer size 32, 118 instances
The same stability problem still exists in this version. In version 13 the performance meter is very stable and in version 14.0.30 it is not. Cubase 14.0.30 needs to be fixed. The meter keeps jumping like crazy. Windows 11
Is your project freaking out and stopping or not playing?
The meter running as it does isn’t a ‘stability problem’ unless you’re project is actually crapping out on you.
Same here,
13 was ok 14 is having problems.
(Nuendo, Cubase on windows and mac al having this issue)
The issue is that the processing of Cubase 14 is not the same as previous versions, even though you can work with the program in these conditions, we notice how it consumes more energy. As a result, I’m having more peaks with it, the meters are not results. Addressing this here is very important, because stability needs to be identical or better than other versions. My sincerity here is the same as many who are having the same problem and seeing the difference in performance between 14 and the others.
I think what @Monotremata is getting at is that the APM in Cubendo 14 is different than previous versions, and that it now reports real-time vs prefetch stats which are more representative of your actual hardware. If you’re not actually having audio dropouts, then it doesn’t really matter what the meters are doing. It’s just a tool to help troubleshoot.
They go into detail on their website:
You’ve got the “same performance” or better than previous versions, this iteration of the meter just shows more accurate data. I think all the other people who have the “issue” just didn’t read what the new measurements are based on, but that’s just my presumption.
Same exact thing happened with Ableton Live 11 when they changed what the CPU meter was actually reading. People started freaking out on their forums too, until the devs came in and let everybody know how it was and if the project wasn’t cutting out or crashing, it was perfectly fine..
Cubase 14 may have a new mechanism to show performance, give us more detailed data and I agree with this new functionality. More would be better, in my point of view, this function does not affect the behavior of the meters, because even though they have greater sensitivity in this version 14, they end up consuming more energy and having easier drops than the older versions. Working on this last night, I realized how much easier it reaches the processing limit compared to version 13. Same design, same buffer settings, etc. I think the new specific function is good, as long as it is stable like the other versions. I hope this is corrected.
I can only agree,
I haven’t really did some tests so this is not
based on ‘messurements’, but I never had load issues before and with CB14 I must say that thing got more critical in this area.
With the same projects I see more moment were ‘overloads’ are ‘around the corner’.
My test shows that C14 and C13 are clearly less efficient. Compared to C11 - C13 and C14 allow you to run a test (a few posts above) of about 7 instances LESS demanding Retrologue VST before the system starts choking and the sound muted.
It’s exactly as if I had a weaker computer that allows me to run 7 fewer VST instruments.
So it’s not an illusion and it’s not “good” because it “plays” and we’re supposed to ignore the meters…
The discussion about new, more sensitive meters is nonsense.
Either way, let everyone do these measurements themselves and compare the performance results of C11, C12, C13, and C14.
Just so I understand, are you claiming that SB has lied about the updated telemetry metrics in the newer APM as outlined in their own documentation? I’m confused how that is “nonsense.”
Sorry again, but what measurements? Are you referring to your “tests?” What were they and how can we perform them ourselves? Or are you just saying “I’ve done tests and this is different so the other comments are all nonsense?” It sounds like that’s what you’re saying, but it’s hard to tell. The absence of any actual testing data, or even something like your OS and interface reduces the value of your “research.” To me, anyway.
More data such as his OS, etc. would be helpful as you say, but to be fair he did provide some testing data from his system (“seven fewer instances …”, etc., paraphrasing).
I think that’s interesting in its own right, and certainly could be a hypothesis-generating observation.
In my opinion, saying “7 fewer” has no value without the corresponding source data of “7 fewer than what?” The difference between 1000 instances and 993 instances is trivial. The difference between 8 and 1 could be considered significant. That of course is predicated on a presumption that “duplicated instrument tracks” is a valid test in the first place - which it isn’t because threads obviously come into play and base system configurations and services (most notably on Windows) can have dramatic impact.
I don’t think any of this actually matters though, particularly when people dispute that the APM is different, or when people say “I haven’t done any measurements but I feel this..” (not the post I replied to, but earlier ones).
I don’t understand what you’re getting at. If you can load x instances of a plugin in Cubase 13 and x-7 instances of the same plugin in Cubase 14, on the same system, how is that not a valid test?
I meant when comparing disparate systems (which was what was originally stated), not within the same system. If C13 = x and C14 = x-7 in a controlled environment with consistent results over a multitude of tests on the same system, that may be helpful to someone. Of course, in the case of what I was replying to, we don’t actually know any of that.
And of course, that’s a completely different subject than the stated changes in the APM being “nonsense,” hence the questions seeking some clarification.
Hi, brothers in arms ![]()
There is a difference in performance metering, as Thor.HOG stated above. I had “standing” bar in previous versions (I guess from C12 on) and I have a lively “jumping” one in C14 (with all the updates). It bothered me quite a lot (with previous versions) , but then, after trying everything imaginable and unimaginable, I just gave up and did not care about the performance monitor anymore, since the meter values did not affect my work. I never ever had any issue of overloading and the meter never peaked to a “drop out zone” even when using a proportional share of VSTs and plug-ins.
To be frank, I do not like warning lights going on in my car and the same goes with DAW performance meter, when producing music. But, as I said, the issue is present in my system from, I believe, C12 on, but it did not affect the performance in any way. It is just annoying, so I do not check it anymore - until I will encounter drop-out issues.
On the other hand - I have been with Steinberg from ancient Pro-24 (Atari) on, but never encountered as many issues and instability problems as with C14… Something went wrong somewhere during the production and version 14.0 just wasn’t ready to hit the market in the time of its release. I admit, I was hasty to upgrade and begun using C14 (foolishly untested) for quite a large production session, only to get into so much issues, that I “downgraded” to previous version. Professional tools like Cubase should not provide such amateur flops.
Sorry, Steinberg, I am with you for almost forty years (yes, I am old) and continue ageing with you, but this time, I admit, you disappointed me.
Oh, I see that you already know what test I’m talking about because for a moment I had the impression that you hadn’t read any of my previous posts when you wrote about “some of my tests”.
But I’m glad that we know that this is about a test:
This is a credible test conducted by dozens of Cubase users and yes - it is a test ON ONE AND THE SAME machine that shows how much the performance of C11 differs from C13 and C14.
Did you read that I inserted also texts REGARDING only windows 11? Apparently not entirely since you write about different systems and an unreliable test (disparate systems).
Windows 11
Cubase 11
Buffer size 1024, 140 instances
Buffer size 128, 127 instances
Buffer size 32, 120 instances
Cubase 13
Buffer size 1024, 133 instances
Buffer size 128, 122 instances
Buffer size 32, 119 instances
Cubase 14
Buffer size 1024, 132 instances
Buffer size 128, 121 instances
Buffer size 32, 118 instances
Instead of getting better, it’s only getting worse. The same sessions have a higher load on C14 than on C11 within the same machine.
Until they fix this it’s hard to argue.
i9-12900K, ASUS PRIME Z790-A WIFI, Kingston FURY 64GB (2x32GB) 4800MHz CL38.
Win 11, 2 x m.2 970 EVO, Noctua NH-D15S, HDSPe AES (RME 4.46)
With a little effort you can figure it out from my profile… ![]()
Sorry, but it’s not my role to look up your profile and presume what you say is accurate. I’m rather surprised you would even suggest that.
And of course I looked at your previous post - I wouldn’t have replied otherwise. The confusing part is that the “7 less instances” is between Win10 and Win11 with C11 in singularity. So even after all of that “testing,” what you’ve actually said is “it doesn’t matter what DAW you use or what interface you use, the difference between Win10 and Win11 is the same as what I claim the difference is between C11 and C14 on Win11.”
I’m not being critical of you per se, (no ad hominem here) but the results you’ve shown - in my opinion - are absolutely worthless. Sorry to sound so critical, but they are devoid of any real, valuable information.
I could just as easily say that based on your own data, there is a ONE INSTANCE difference between C11 and C13, and only a 2 instance difference between C11 and C14 for a buffer of 32. That 2 instance difference is 1.6%, which is about 1/3 of what the statical error rate would be after hundreds of tests.
Meaning that even in a controlled environment after hundreds of tests, the error threshold alone is 3x that of the variance claimed. So sorry, but that is utterly meaningless.
And you’ve still not articulated your justification for stating that the published telemetry metrics are “nonsense.” In all transparency, my question in that regard was mostly rhetorical as one can’t effectively dispute the published data from SB by presuming other published data from SB is wrong.
It really doesn’t matter, and this is why I say the “tests” have no value. Your one set of results supports and refutes BOTH questions of C11 v C14 and Win10 vs Win11 at the same time.
All that said, if you want to believe that data, and take action based on it, that is 100% your prerogative. I just don’t think you should try to tell other people it’s “correct.”