I’ve tried it at various FPS limits, block sizes, and audio thread counts and I have to admit I’m not seeing a significant improvement at any block size. Interestingly the audio thread count seems to inflate the remaining mS available but it doesn’t seem to help. For example at 30fps with 512 block size I’m getting a tonne of stutter but sitting at around 350 mS with 2 threads. Even so with 1 thread I’m at >150 mS consistently yet I’m still getting a tonne of stuttering.
It seems definitely helpful, but not enough to get my MacBook to work with this patch right now
I’ve been trying out the multithread version (totally distracting me from working lol), and on my 2017 MBP I can use framerate 30 and 3 threads to get what seems like much better performance, at least I’m able to screen record video/audio and patch/modulate/wiggle without glitching. Temperature is showing 137, however, the fans are not screaming atm. I do have the MBP on a cooling pad (which from what I read doesn’t help much at all).
@JimT I don’t -think- I saw much about it on here yet… Think the experimental build might help out a 2 year old AMD quad-core A10-9600P 4C+6GPU?
If it’s any kind of benchmark, Valley Plateau runs about 120-150 miliSquirrels, and Frozen Wasteland Portland Weather about 1400 mechaSqueaks (which reminds me, I need to figure out bug reporting on the Klirr Factory PW - I never got it to load ever)
You’ve got 4 cores, so it might do something. However, PW taking >1000 squirrels probably won’t run given any number of cores, looks like it’s taking longer than 1 sample time to process 1 sample and the MT patch can’t make an individual module run multi-threaded. The only hope for PW is faster single core performance, but once you’ve got that, you can run the other modules on a different thread using the MT patch whilst PW takes up its own core.
Reducing FPS might help out too (in some voodoo, unspecified way).
This is definitely helping hugely on newer patches I’ve been making. I think maybe Dexter was causing a lot of issue for me.
Biggest benefit is that on 30fps my fan is not going anywhere near as mental and it doesn’t feel hot at all, which was a huge issue that would start pretty quickly after adding even a small number of modules!! So thanks very much @JimT
Another thing I discovered that improves performance greatly to me is Squirky Labs’ Thread Booster. On my mac this makes it so I can actually browse chrome with VCV Rack running my music without unbearable amounts of stuttering. On real-time i actually get no stuttering no matter what I do but chrome sometimes hangs, but I don’t mind that. Definitely a life saver module I wish I knew about!
Here’s my first proper patch with this new VCV Rack. Thanks again @JimT! 8th jan.vcv (82.8 KB) (don’t forget to hit reset on CLOCKED to make sure everything is running, thread booster is to the right of Audio if you have issues with it)
I’ve never used SevenSeas and don’t have time to figure it out right now. I can maybe try tonight.
DeepNoteGenerator is ~240mS on the i9 MBP.
I don’t think this is the right box to be testing on though as I am in the ‘overheating MBP’ group, not the ‘old machine’ group, of possible beneficiaries of Jim’s mod. The multithread mod might help an old machine that is struggling with it, whereas I benefit from being able to reduce the GPU frame rate.
Deepnote works fine in multithreaded. Adding it to joe’s patch does cause stuttering on my windows laptop just before the crescendo. Adding a second thread lets it run cleanly. I can’t give meaningful figures on 2 threads as the cpu counters get a bit screwy - I haven’t adjusted their math to account for the extra threads. It won’t use more or less CPU, it just runs deepnote on the extra thread and is fine.
FPS limiting has no effect.
Forcing 7seas to run on the engine thread is much the same story. Although I haven’t figured out how to get a sound from it yet. It’s current sitting on ~60mS, it’s happy getting processed with an extra thread.
With my SevenSeas experience I will say I used to have mS issues but for some mysterious reason not anymore. If i see some stutter in the module i just set its block size to 512 samples and boom! no more annoyances!
To quote the VCV manual:
Rack measures the amount of time spent processing each module in mS (millisamples). This is a unit of time equal to 0.001 / {sample rate}.
To maintain a stable audio clock, the total amount of time spent processing all modules must equal 1000 mS . To achieve this, the Audio module from Core uses your audio device’s high-precision clock to regulate Rack’s engine, so it idles for the remaining mS until this total is met. If the Audio idle time falls close to an average of 0 mS over its block size, an audio stutter may occur. This can be caused by other modules consuming lots of mS.
I’m no audio engineering junkie but from my experience, I think it’s talking about the fact that using a metric ton of mS (which apparently is a time measure) can cause noticeable slowdown in the patch itself, due to the power hogs preventing the sound to get in time. But dang if I know fully about processing time and all that stuff.
