So in fact there is no significant difference in CPU load. Truly, interesting. But what is the ASIO Guard Average Load indicating? Can someone shed some light on this?
Nay, I didn’t “get you”. If you are hanging out in this forum a lot eventually you will see somebody starting their message with “I asked ChatGPT…” or “I googled this…” and those machines will then have presented some random text from this forum.
ASIO Guard has a fixed size. To us it is shown in milliseconds but it is actually an amount of samples. Furthermore it works in packages, ie. the amount of samples is wrapped into one package and then delivered to a certain place in the Cubase audio engine. Any further audio signals will be put into the next package. It is a boxing service if you like.
My GUESS is: The meter shows how many of the available samples per package are actually filled up with data, ie. how full the box is (and how much empty space is left inside).
I think your position is perfectly reasonable. This is just my own opinion, based on observation and effect in my own environment, but I may suggest zooming your scope out a bit and looking at the APM more as a potential troubleshooting tool for when you are experiencing an issue, rather than a metric by which you evaluate current system performance. Please do indeed conduct your own research, as that’s the best way (I think) to apply what is important to you and your particular setup. If I were to look at the APM results for Cubase in isolation, I very well may infer a performance issue just based on the scale of the metering and the “jumpy” activity. The below is a screen shot of BOTH Nuendo 14.0.30 and Cubase 14.0.30 running simultaneously, but each with different projects and different audio/CR configs (which is also an important consideration):
Interesting, right? Again, that screenshot was of both running at the same time, not two different screenshots put together. Now if we mentally zoom out and look at the overall system, you’ll see that the actual CPU activity tells a different story:
Just for context, that’s with my system running C14, N14, Live, Max, Apple Music, SL11, and WL12 all at the same time. The SPL11 project is even set for 32k FFT frames (which is quite a bit). Usage will obviously change based on activity in each app, but you can see there’s plenty of available processing power - granted, this is a rather supped-up Mac rig, but the concept is the same, and it’s a rather important consideration as obviously the “25% ASIO-Guard” indication on the N14 app doesn’t reflect what is actually going on with my system.
The only reason I’m bringing this up is to point out that the APM metering is very contextual, even between Cubendo apps, and most importantly, as it relates to the overall system performance.
I wouldn’t stress it. I don’t even look at the APM unless something funky is going on and I want quick glimpse into what Cubendo thinks is going on. All just my thought with a wee bit of context.
I agree, particularly within the context of how the current project applies to the app audio engine, with the added caveat of current system threading/scheduling. If I load the exact same project in N14 as did above without other audio apps running, my ASIO-Guard metering drops to about 18% or so. If I change the project to 96k, it then increases to about 28% or so. I also do not know the exact components being measured, their “weighted” relevance, etc, but from an observation perspective your description makes sense to me.
It measures the time to fill the current asio guard buffer in relation to the asio guard buffer size. If the asio guard buffer is 10ms (to keep it simple) and it takes cubase 5ms to calculate that buffer, it will read 50%. If it takes 2ms 20% if it takes 11ms you will get an overload and a big dropout. It is that simple. Asio guard load should give the same results in C12 and C14. If not there can be settings involved like suspend vst3 plugins with no audio (which lowers the load) or if there is a track record enabled. Also cubase might spread the load differently in different versions, but you would have to load a project with many many plugins and a very high load like 90% to see if one or the other is more efficient.
Well okay, but then there is some difference between Cubase 12 and 14 even though the CPU load seems to be equal for both (at least for my project). In both Cubase instances “suspend vst3 plugins” has been disabled, the ASIO guard level has been set to “high”, the buffer of the audio interface is set to 1024 samples. The screenshot from my most recent post shows the project right after loading and playback of a few bars. The ASIO average load is ~52% for Cubase 12, and peaks at 82% for Cubase 14 (but is roughly around 60% when not spiking). So does this mean something is slower/worse or whatever?
–
Maybe this is too off-topic and should be discussed in a separate thread?
It is same same. As long as the project runs well, the meters don’t matter at all. Way too many people get excited about the flickering on those meter bars.
Every single reply in this topic should have been a separate thread. What is the point of replying here? But it is the same on every single release.
Can you please explain in details if that specific bug fix/improvement is related to the midi jitter problem that causes the clock to be sent with unstable timing and consistency when syncing external gear through midi clock ?
• MIDI Clock delay compensation is now correctly applied to external instruments, even with complex setups
I don’t know in total what I’ve spent. I started a long time ago with 4.5 Studio. It has been a great investment. I simply cannot believe how far this software has come. I’m in awe of the capabilities, the included plugins, the included instruments, the mixing and mastering capabilities, the (relative) ease of use, the performance, and more. And now there’s a score editor I can understand, that arrived exactly when I needed it.
A few issues I’ve noticed, so far, since installing 14.0.30:
The jog wheel on my Icon QCon Pro G2 now only allows me to move forward in the project
After editing an audio event in the lower zone, deselecting the event doesn’t clear the lower zone; I have to close and reopen it in order to clear it.
This is probably the weirdest. So I copied an audio event from a track that’s got its channel panned to the right, and pasted it on a track with its channel panned to the left. Everything else on the channel panned to the left played on the left, except the part I copied, which maintained the panning setting from the channel panned to the right.
So I’m about to uninstall 14.0.30 (which seems to be a necessity) and reinstall the previous update. I blame myself; I should have waited, like I normally do.
UPDATE
That was me not being as observant as I should have been; the automation was also copied with the part.
Has the ‘Track Delay’ been fixed in this update after nearly two years of asking?
By this I mean allowing us to once again make fine adjustments of .01/.02/.03 values on the fly via the keyboard and hear the result in real time without having to type in a numerical value or resorting to using only the mouse in larger .10 increasements.
Something that users with 2 or more screens criticized about Cubase was that the editors, like Key or Sample Editor would close automatically when they were opened in their own window and nothing in the project was selected anymore.
I wonder if that has changed now and what you describe is the consequence of this fix.
After downloading, installation fails and then I get a message to double click the Cubase file that’s already been downloaded. When I do that, I get this message: