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.
2 Likes
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.
2 Likes
Yes - works fine on small patches, but wall of noise on the larger ones where I’m worried about resource consumption 
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
Yes
If you’d like to be on Mac have a serious look at the M1 machines…
2 Likes
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
Had the same issue, but the fork worked for me!
1 Like