Can we please have some kind of meter?

[ColinP]

One of VCV Rack's solutions to the heavy GPU draw is to offer variable frame rates. I'd be interested to know what GPU capacities you experience at the different frame rate settings.

I tried 30 FPS and that drops GPU to about 18% but that's still ridiculously high.

Dropping it to 20 FPS produces about 13% but then we are getting into the jerky range.

Also this is just with the start-up patch not something with fancy graphics.

[ColinP]

I realise that this part of the forum is for general readership. So I apologise for posting something very techy that perhaps ought to be posted elsewhere. Please just skip this post if you aren't interested in developing for VM.

But if you are a VM developer (or thinking about becoming one) then this discussion has digressed to VCV Rack so I think it might not be totally unreasonable to expand on the SIMD thing I mentioned earlier and look briefly at the kind of things that C++ programmers are faced with trying to get the best out of VCV Rack.

Here's some light reading...

https://community.vcvrack.com/t/whats-t ... -code/3774

[theWholeSandwich]

even freeware LMMS has one of those. cpu overload sneaks up on you in VM. next thing I have is a song I can't use

[TheGarnet]

There needs to be the option to switch on some kind of performance meter in VM.

Yes one can use a general purpose CPU performance tool to look at CPU load but that's a bit like trying to find out what time of day it is by using a light meter.

I am having glitching problems on a top of the line Apple pre-M1 i9 laptop, just by doubling one of the Miniverse examples. I had wanted to use LSSP techniques to automate a few minimoogs, but my hopes of exploring that are rapidly fading since VM cant run even two copies of of a reasonable patch without glitching.

Saving cabinets is really cool. I ran into this glitching the first time I tried using this feature. Without the ability to run two or three cabinets of a dozen modules, I wont get much opportunity to make use of the saved cabinets.

I have looked at Activity Monitor, and VM, with the doubled "Brass Pad V1" is showing 89% CPU just while sitting quietly behind this window.

I went back to that window and hit a few keys at the same speed I type, and glitch city on the audio. CPU never went about 92%. % GPU stayed at 0.2.

So I concur:
1) VM must warn the user that it detects timing to create a proper supply of audio packets is failing
2) External CPU performance monitors are utterly useless on a Mac to give any insight into VM's failure.

Edited:

DOH!

I just tried selecting "Use multiple threads for mixing". By doubled Brass Pad V1 is working a lot better now... In fact I now have 4 different miniverse presets running at the same time, for cpu steady at 188%.

Arwen cleaned up nicely too. It glitches just a little as I am typing in this browser window while it is playing. It's CPU is holding at about 325%. When it glitches because of what I am doing in browser window, there is no hint being given by CPU jumps in activity monitor.

So another suggested feature for VM:
If VM were to detect audio packet supply problem, it should have suggested that change to settings.

[huggermugger]

I'm in. VM needs a CPU meter, per module. If I'm having performance issues, I want to know who the culprits are, so maybe I can switch things up.

[UrbanCyborg]

+1 on the metering, but also +1 on Roland's suggestion of non-real-time rendition. Back in the day that was the only way (ah, the joys of a PDP-11 ). There are still occasions when it would be nice to swap time for clean execution of complex CPU-loading presets.

Reid

[ColinP]

Given that it's six months since CA updated VM I have low expectations of any revolution in functionality.

I know Robert says that all suggestions are logged but how many suggestions have actually been implemented? My conclusion is that it's easier for CA to make money from their vintage emulations than by upgrading VM.

So for me the top priority has to be just basic metering as this is something that could be added without much developer resource.

Huggermugger, one could infer individual module load by removing modules - less than ideal but it would be a workaround if we at least had a global meter.

Reid, yeah non-realtime rendering would be fantastic. Especially for people like me who build fully automated patches. But for people playing VM with a keyboard it's not really anything of interest and I suspect that that makes it an unlikely addition.

I'm generally an optimist so I hope I'm wrong and CA are secretly devoting massive amounts of developer time behind the scenes to surprise us all with a VM 3 sometime in the near future.

[seal58]

I hope so too. - But ...

CA needs several weeks and months for fixing of known issues. So it looks, they don't have any time for upgrading the system according to user wishes.

[ColinP]

CA needs several weeks and months for fixing of known issues. So it looks, they don't have any time for upgrading the system according to user wishes.

I might agree if CA hadn't developed and released Dreamsynth, Miniverse, Lowdown, Rackmode, Galactic, Miniverse Modules and Elka-X since the last update to VM.

[cherryaudio Greg]

Hi,

We've got a small team of developers, and they have to prioritize what they work on. Each feature suggestion is being weighed against fixing bugs, other feature suggestions, and as you mentioned, other products. We're committed to the continued development of Voltage Modular, but we can't guarantee that any specific feature suggestion will be acted upon.

Greg