Per-Plugin resource meter

Know when you’re running out of CPU juice and need to start freezing tracks or temporarily deactivate plugins?

I’d love to have an option where you could easily get some insight into where your CPU power is going!

It would be great to know which plugins are most CPU hungry so you could deactivate them first.

Not sure if this is at all possible?

The per-track ms report is REALLY helpful. Thanks Steinberg!! <3

If you’re referring to the latency-readout in the Mixer, then this is not necessarily reporting the CPU demands of the plug-in(s) in the respective track. Quite contrary: The more time a plug-in is allowed for its processing tasks, the less load it burdens the CPU (… as a rule of thumb).

1 Like

Hi Dietz,

Yeah, I’m referring to the latency-readout in the mixer, and while your explanation makes perfect sense - at least on paper - in practice I find that a lot of my more latency demanding processors are in fact often also CPU power hungry.

I think the point you’re making holds up if the processes evaluated are roughly the same for higher or lower buffer sizes. For example: a lookahead function in a compressor. Engaging lookahead would increase the buffer size, but it would take roughly the same amount of processing power to do the actual compression, thus lowering the stress on the CPU.

However the element missing from this reasoning is that usually (at least in the plugins that I work with) the higher buffer size goes towards things like oversampling, or certain precision or quality settings that require both a bigger buffer size and more CPU power to crunch. I’m not saying your point won’t hold up in this case as well, because in essence the higher buffer size could account for less stress on the CPU however in my experience the higher demands due to oversampling/quality/etc overshadow the buffer size increase.

In short, often I’m often able to zero in on CPU hungry plugins by checking the latency readouts much faster then without those. Of course in the end you need a bit of common sense as well, and without an actual CPU stress meter, in some cases it is still a mystery where your processing power is sapping off to, but it helps!

Small caveat for your reading pleasure: Increasing the buffer size, even on a process like lookahead doing anything for your CPU only holds up if programming is done right, and taking advantage of this extra buffer size. In the case of lookahead for example, if the extra buffer size is only being used for the detection algorithm, and the actual compressor only doing any crunching after the extra buffer size has passed, it will effectively add zero percent of the extra buffer size to the actual number crunching, and thus not lowering the stress to your CPU. Audio being a real-time serial process, this sort of thing might actually be more complex then you’d think at first, as it is hard to start doing any compression while the detection process is still running. Come to think of it, lookahead is actually a prime example of an increased buffer size that does pretty much nothing for the stress on your CPU. :melting_face: