Hello
In my patches, I know I need to run into optimization when I hear some glitches when moving the mouse over cables or panels 
Then I need to work on automate the arrangement, click on record button hoping it will work fine.
Never found where is the limit in term of modules, didn’t test.
have fun
That’s very odd. And setting the Engine thread(s) to “realtime” doesn’t help?
I already set realtime. I just reopen the patch to answer your message and checked. Usually I’m using 2 threads (i5 - 4 cores) without a glitch With my last patch I moved to 3 threads to avoid glitches (setting 4 makes all audio glitchy) I’ve decrease the frame rate and set 1024 for the audio buffer (48kHz)
And I did the test again, moving the mouse over the module brings glitches to the sound :D… maybe vcv is rendering something beneath the mouse (over Clocked, Mindmeld mixer as example)
I’m on MacOS 10.14 and I’ve seen the Rackv2 message about moving to Metal… should provide enhancement in the future, fingers cross 
have fun & make music
In the sections: Only do expensive calculations when necessary / Lower Sample rates - is this as simple as having logic in the module’s process() method e.g. a counter that only runs a block of code every 16 calls? Or is there some other mechanism where rack calls something at a lower frequency?
That’s what I do. There is even a divider in the VCV source for this, although I don’t use it. Here’s where I use this technique in the Demo VCO: Demo/src/VCO3.cpp at 496a40fce819dd2a00a565fd8c8a1cd731891c85 · squinkylabs/Demo · GitHub
Andrew has pointed out that lowering the sample rate of the FM input like I do will change the sound, and probably not for the better. It’s a trade-off I’m happy to make, but you do have to think through what the effect will be of things like this. Oh, and btw, my VCOs have much lower CPU usage than most.
Got it, thank you.
If you look in Basic VCO I use two different dividers. Every 4 samples for updating pitch, every 16 for looking at knobs and such. Usually when I do these I benchmark them, then I double the divider values and re-measure to see if I’m still doing to much in the divided code path.
Thanks again. These patterns are really helpful. The art of coding with rack.
Interesting thread, ‘it all depends’ is the answer. I don’t care what % utilisation is reported, as long as it sounds OK. With synth sounds and the highest buffer setting, 40 or 50% is no problem. But using Rack to process live input with any reasonable latency, I get horrible glitches/stutters/break-up at less than 20% (going off Task Manager in Windows). This is on a new Dell G7 gaming laptop with i9 CPU and decent graphics. Annoyingly, my fairly ancient i5 desktop can run the same patch using >40% before the sound craps out. This is due to thermal throttling on laptops, and poorly written system drivers that aren’t suitable for realtime applications (google “Dell DPC latency” to see the problems people are having with audio software). But to answer your question, 60% plus is probably fine for regular patches in my experience. For running tons of effects modules + low latency, CPU isn’t the only issue. Cooling, audio interface, graphics performance and OS/drivers are all big factors.
Now I’ve been working with Rack for a while, I have an answer to my question which is - on Windows 10 - to keep the number of modules in a patch low small enough so that it can work without stuttering with the engine on one thread.
I used to run it on two threads (on a two-core PC) but now I understand there’s a lot of overhead and it uses a lot more CPU. Don’t understand it, just observe it.
This is now my rule of thumb. Means I don’'t run the massive generative patches that I see and enjoy here, but my ‘little’ 45-module patches keep the fan running on low are still very useful. And equate to, what, £3,000+ in Eurorack hardware? So can’t complain 
It’s my understanding – and observation – that this is the way rack is supposed to work.
As others have said in the thread, the way that Rack supports threading is somewhat different than most multi-threaded applications. If you set one thread Rack will try to make maximum use for that, so for a patch of any complexity you could see 100% utilization. If you have two thread you could see 200%, etc. And yes, I’m sure there is some overhead in the context switches.
My day job right now is a writing distributed, high-performance Bayesian calculation engine, and while it may be somewhat counterintuitive, I spend my days trying to get the software to use as much CPU as possible, not as little. I think Rack (correctly) operates in the same way. It tries to use as much CPU as possible, and the thread count is your way of setting limits on that!
I understand it a bit differently: Rack doesn’t use any more CPU than it has to. A patch uses what a patch uses, no more, no less. Some workloads in some programs are very easy to parallelize, others are very difficult. My sense is that Rack is somewhere in the middle. So in Rack, the way to use it is to always start with one engine thread. Only if/when your patch gets big enough that the audio starts to break up, you increase it to two threads, and so on. Because of the way that Rack uses threads there is a certain non-trivial amount of overhead to using multiple threads; in other words - adding more threads is not for free, and that is why you should always use the minimum amount of threads that you can.
@LarsBjerregaard this is also how I believe it works. I think it has changed a little bit during the time 1.0 has been out, and I believe that in 2.0 the overhead per thread will go away. Which would, if true, make Rack act more like other audio software. But yes, for now “add threads as you need them” is what most people recommend. I might be tempted to go all the way to (cores - 1) without experimenting, but your way will always work.
Mate, I have the same issue, as soon as opened CVC rack my computer’s fans instantly starts to make a horrible sound and my macbook pro gets warmer instantly, if by any chance you find a solution let me know. I have a macbook pro 2015, core i7, 16 ram, It’s sad that I can use CVC rack because of that.
Thanks. Some confusing concepts in here for me!
I prefer the simpler idea of…
…but you know know what the physicist said about making things as simple as possible 
FWIW here’s my CPU graph, running Rack on one thread. I’m never sure how much to trust Windows Task Manager reporting, but it looks like both cores in play. Not sure how one thread gets to work with two cores, beyond my ken.
Windows task manager is good for showing you what goes on, on the whole computer. If you want to track the CPU usage of one process, like Rack, you can’t really use it. I recommend using “Process Explorer” from Sysinternals (free). Right-click on the Rack process and select Properties and then go to the “Performance graph” tab. Now you’re looking at the CPU usage of only the Rack process, over time.
Is it not the case that while the audio engine of rack is using one thread, there is also a thread running the rack GUI.
Ah, that makes sense.
Excellent, thanks. Here’s what’s going on in ‘Threads’. Lots of threads!
And in performance, I guess the I/O is the autosave function? I have noticed glitches when I run something else that requires disk access - or so it seems. I think the autosave is a really good features, but I wonder if for optimising performance it’s a thing?
Yes, looks like it. You don’t have a SSD? I know other people have played with lowering the autosave frequency. I think if you search you’ll find posts about it.
Sadly I have the old spinning disc on this laptop - yuck. OK, got it thanks - something to experiment with.
