Voltage Modular, Please show the CPU usage meter and a switch to turn it off.
Most modules are heavy on the CPU and affect latency. We seriously need to know how much it eats up CPU.
Also need a switch to turn off before freezing.
This has been mentioned before and please implement them in the next update.
Where is CPU meter
-
Centripidity
- Posts: 146
- Joined: Sun Jan 22, 2023 5:18 am
- Location: Melbourne
- Contact:
Re: Where is CPU meter
Thanks. Didn’t know someone developed it as a module. But it should be the part of UI..
Re: Where is CPU meter
It's an issue which has been talked about already in this thread:
Can we please have some kind of meter?
The CPU Load Meter by Nrgzr78 doesn't really go deep enough to identify the specific load of individual modules, unfortunately.
Can we please have some kind of meter?
The CPU Load Meter by Nrgzr78 doesn't really go deep enough to identify the specific load of individual modules, unfortunately.
______________________
Dome Music Technologies
Dome Music Technologies
Re: Where is CPU meter
I agree that some built-in resource tools would be helpful. However, an overall CPU monitor for VM would not serve my needs. I have found that tools are needed to assess each individual module's efficiencies and inefficiencies.
For example in preparation for developing some of my own midi modules, I created a first draft of a simple channel splitter/router with feedback (midi data in hex). And when I began using it in test presets to developer my test module further, I started having issues.
The first thing I usually do is "blame myself" in the sense that I did something wrong. However, I discovered that some other modules (third-party modules) in the preset and evidently their use of midi were causing the problem I was seeing. Phew!!! Glad it wasn't my module.
And while audio artifacts (glitches) do tend to increase with higher CPU usage, in my experience other things can cause issues as well. My point is that while CPU meters can be helpful, more tools are needed.
Using my example, while issues with midi processing might show up with some sort of CPU monitoring tool, (1) they might not and (2) they might not point to the source of the problem.
To me just having a CPU meter is problematic in part because even if there is one built-in, it could give a false sense of security.
For example in preparation for developing some of my own midi modules, I created a first draft of a simple channel splitter/router with feedback (midi data in hex). And when I began using it in test presets to developer my test module further, I started having issues.
The first thing I usually do is "blame myself" in the sense that I did something wrong. However, I discovered that some other modules (third-party modules) in the preset and evidently their use of midi were causing the problem I was seeing. Phew!!! Glad it wasn't my module.
And while audio artifacts (glitches) do tend to increase with higher CPU usage, in my experience other things can cause issues as well. My point is that while CPU meters can be helpful, more tools are needed.
Using my example, while issues with midi processing might show up with some sort of CPU monitoring tool, (1) they might not and (2) they might not point to the source of the problem.
To me just having a CPU meter is problematic in part because even if there is one built-in, it could give a false sense of security.
Re: Where is CPU meter
It is extremely disappointing that VM still doesn't have even basic performance metering.
But there is some subtlety to what exactly we are talking about here. "CPU meter" is a very vague term.
There are already tools for looking at overall CPU performance but even within these there's a lot of complex detail. For instance I use Sidebar Diagnostics as shown below.
Now there's a headline "Load" figure but one needs to interpret it carefully as it depends on the Clock rate - which can vary an awful lot on a laptop depending on power management settings, temperature and opaque details deep inside the lowest levels of your machine.
And this load is just an average of what's going on over 16 cores in the case of my CPU. So although the headline load is 13.93% you can see that Core 2 is running at 60.59% and Core 9 is having a nap.
But none of these figures relate closely to what most of us are interested in when using VM.
The metric that really matters is how close to not being able to fill the buffer in time we are. When the buffer can't be filled in time it's a disaster as the audio engine simply can't do its job fast enough - that's what causes the nasty distortion and crackling noises.
The other metrics we are interested in is how much time each module uses to exectute its ProcessSample() method. This can either be expressed in absolute time or as a percentage. We would then be able to see that module X was using up most of the resources while module Y was using almost none.
These metrics can only be measured by having the kind of access to inside VM that CA has. So it can't be retrofitted by a third-party module. Although I guess a module might be able to crudely estimate overall performance if it knew what the buffer size was, made certain assumptions and analysed its own timing pattern.
But there is some subtlety to what exactly we are talking about here. "CPU meter" is a very vague term.
There are already tools for looking at overall CPU performance but even within these there's a lot of complex detail. For instance I use Sidebar Diagnostics as shown below.
- SidebarDiagnostics.png (223.44 KiB) Viewed 1902 times
Now there's a headline "Load" figure but one needs to interpret it carefully as it depends on the Clock rate - which can vary an awful lot on a laptop depending on power management settings, temperature and opaque details deep inside the lowest levels of your machine.
And this load is just an average of what's going on over 16 cores in the case of my CPU. So although the headline load is 13.93% you can see that Core 2 is running at 60.59% and Core 9 is having a nap.
But none of these figures relate closely to what most of us are interested in when using VM.
The metric that really matters is how close to not being able to fill the buffer in time we are. When the buffer can't be filled in time it's a disaster as the audio engine simply can't do its job fast enough - that's what causes the nasty distortion and crackling noises.
The other metrics we are interested in is how much time each module uses to exectute its ProcessSample() method. This can either be expressed in absolute time or as a percentage. We would then be able to see that module X was using up most of the resources while module Y was using almost none.
These metrics can only be measured by having the kind of access to inside VM that CA has. So it can't be retrofitted by a third-party module. Although I guess a module might be able to crudely estimate overall performance if it knew what the buffer size was, made certain assumptions and analysed its own timing pattern.