Objective way to measure VCV Rack performance? (acceptable on Mac)

I am a relative beginner with VCV, but have already run into what I believe are hardware limitations on my current setup. Most of Omri Cohen’s demos stutter. I’ve set frame rate to 10Hz, limit the number of threads, marked Rack to open in Low Resolution Mode. Those settings help, but I’m still limited to very simple patches.

I see screenshots of monster patches that I have no hope of replicating on my setup. I might consider buying new hardware, but am reluctant to spend too much on fancy hardware only to find that it’s still not enough for Rack.

I’ve scoured the forums looking for hardware advice – but don’t see anything objective. I’m on a 16G 2.7GHz i5 Macbook Pro (and I’m aware that laptops with integrated graphics are not recommended). Yet I’ve seen forum posts of other mac laptop users claiming good performance, but “good” is probably subjective (how many modules in the patch? What frame rates? In my ideal world, I’ll be able to run large VCV patches on a mac since that will integrate with my Logic Pro based workflow better as I get more ambitious with my patches. I gather that Windows machines with “gaming” GPUs are probably a better bet, but everything else I’m doing music/audio-wise is on the mac, so would really like to find a way to run VCV on macos.

But how beefy of a mac is necessary? Is a 2015 iMac with RADEON GPU “good enough”? (and again, how best to quantify “good enough”?)

1 Like

Maybe you find some tips here Mac/PC Optimization Guides | Sweetwater

1 Like

You should consider using @diimdeep 's fork of Rack which has real time priority audio for Mac.

I also found it helpful to set a very large block size. I am using 2,048.

I am producing stutter free sounds on an 2-core i3 with no dedicated gpu while filling four rows of Rack with modules to fill a widescreen monitor.


Most bang for the buck: turn on the cpu meters to find out how much cpu your modules use. Avoid ones that use too much.

1 Like

I wish I understood how much is too much. I see very few modules above 4%, most less than 2%. Then there must be some modules that while using lots of cpu are doing the work it would take several simpler modules to do.

I admit it’s not always easy to find replacements. Sometimes you will find a module that is using a HUGE amount of cpu - then it’s pretty easy to decide if it’s worth it to switch. Also, when you are initially evaluating a new module make sure to check.

I would like to say “just use only my modules and you will be fine”. But of course there are all kinds of things out there, and just using one set of modules would be impossible or at least very confining. fwiw - mine use very little. if you have a favorite module that uses “too much” CPU, ask the maker to fix it. Many times it’s pretty easy - I’ve seen many cases where this happened.

1 Like

Yeah, I have found one or two modules that used insane cpu and just forgot about them as an option. But some modules that do use more than most (like Blamsoft XFX Wave) I still use because I like what it can do and am willing to accept the “cost”.

How do you measure performace of your modules? I assume you are not relying on the cpu meter in Rack as the final judge. And does using multiple threads make the cpu meter less meaningful? I have compared cpu for osc’s and don’t see very low cpu usage from SL modules on my system. Since I take your word that your modules are efficient, I am left assuming the meter is not a great way to judge actual performance.

Here is an example…

These are the osc’s I am using most, with the same pitch sequence running through all.

haha - btw, while Functional VCO was in it’s day a clone of Fundamental VCO-1 that used 1/4 the CPU, it is now a little long in the tooth. Some people still like it (obviously), but the current Fundamental VCO-1 is (imao) better. My BasicVCO is enormously more effecient. ok, end of detour.

For my own modules I have a very very precise was of measuring the efficiency, but it only works on my modules, and requires writing code even then. So for comparing with other modules I do use the CPU meters. I have found:

  • they jittered a lot with my ancient m-audio sound card, but they are fine with my new steinberg ur22c>
  • I always use one thread.
  • If the number are too small I set the sample rate to something insanely high to get bigger numbers.

Oh, and by the way, Bogaudio modules are usually very good on the CPU usage.

1 Like

@flyingLow Thanks for the pointer to @diimdeep 's fork! (and @diimdeep thanks for the fork!!). I just fired it up on an old Omri Cohen patch I’d been having problems with and it’s running very well! (early-2015 MBP, 16G).

Is it normal to have audio go completely stuttery when the CPU meter is turned on? With standard Rack, it was unusable for me. It’s better with the @diimdeep fork, but on a large patch (I’m currently running a 3-row approx 30-module patch and as soon as I turn on the CPU meter, it is just static noise…

I don’t usually test with the sound on, so I’m not sure. But this does not sounds right. Unless you are already right at the CPU limit, Then the small extra CPU for the meters could do it? Try with a smaller patch and see?

1 Like

yup thats the problem with using the cpu meter. it will kick up cpu usage considerably.

@diimdeep fork and remember to “disable port lights” under “view”.

this plus the advice already mentioned you shouldnt need to be in low res mode anymore.


Yes - works fine on small patches, but wall of noise on the larger ones where I’m worried about resource consumption :slight_smile:

1 Like

Disable port lights does seem to help. Thanks for all the ideas - My laptop is behaving much better (mostly due to the @diimdeep fork I think, but each little thing helps a bit.)

I’m feeling much better about being able to get more serious about VCV now…

1 Like


If you’d like to be on Mac have a serious look at the M1 machines…


Yup. It was a long time before I found out about changing the block size. Even just bumping it up from the default 256 to 512 made a world of difference.

Form me (Win10, Intel i7), 512 is the absolute minimum for serious music making.

How much difference should i hear?

When I minimze the block size under 512 (say 256 or even 128), it is likely that stutter in the audio output occour (namely the OPs problem).

1 Like