More and more lately I’m reaching the stuttering unusable “too much CPU for too long” stage when working on an admittedly complex piece of music in Renoise. I can see the percentage meter flying up as I hit play and I just know it’s gonna stop the song. Frustrating!
What do you folks do to keep the CPU as low as possible (apart from rendering off a CPU-heavy pattern)? Are there any tricks that work for you, be they within Renoise or other system settings? I’ve heard turning off the wireless card is one, perhaps switching off antivirus software, but that might be anecdotal.
It’s getting to the point where I have to render the song to hear it play properly - then do my tweak, then re-render - not ideal.
I’m running Renoise 3.3.2 on Windows 7 PC with a Samsung SSD installed. I have a NI Komplete Audio 6 soundcard. There doesn’t seem to be an option to extend the latency within the audio preferences of Renoise, but I have the process buffer and USB buffer within the Komplete Audio control panel maxed out.
If you haven’t already, lower the sample rate to 44100. Raise the latency in the settings so there is longer delay before you hear the audio, the longer it is, the less cpu will be used. Activate performance mode in windows operating system (sorry I have no windows, you have to research yourself.
You can also adjust many settings in songs… If you use the renoise filters or distortions, deactivate oversampling in every instance, or at least those not critical. Maybe some plugins have their own settings, too. If you use the convolver, you can try to turn down the length of the reverb if it is not audible. In the sampler, use a lower cpu interpolation mode for samples where it is not critical.
Thanks, all. Am a fiend for non-native effect plugins and softsynths (particularly processor-heavy ones, for some reason)! Am keen to find a solution that doesn’t involve rendering off tracks as I go, as quite often I’ll need to go back in to those to tweak them. So really a make-my-PC-as-efficient-as-possible fix so I can continue my densely programmed tracks without having to switch to native Renoise effects or rendering tracks.
@stoiximan I have a Lenovo T520 Thinkpad i7-2670QM 2.20GHz 64-bit with 16GB of RAM and a Samsung SSD running Windows 7 Professional.
@Garf Yes, with a buffer size of the apparent maximum of 1024. I wonder if I can increase it further? I think that would solve a lot of my problems. I really don’t mind latency at all when using Renoise.
ahh - fair point, Jesse! I shall soldier on for now - I might reoptimise my settings to see if anything has gone askew. And I generally leave antivirus software running the whole time - maybe I need a non-web-enabled machine for music.
On that note, does anyone have experience of migrating a music software setup from an older PC to a fast, modern one? I have countless plugins - I suspect it’s more than just a case of copying and pasting from one to the other. Not to mention various DAWs, including Renoise and Reaper. The thought of this “world of pain” of moving my music setup to a new machine is one of the things that keeps me wedded to this admittedly sturdy Thinkpad.
As long as your .dll files of your plugins can be found in your plugin folder you can “copy and paste” everything into your next PC system. But if you’re using WIndows of course everything else has to be reinstalled completely new again, all your DAWs, all other plugins which can be found in your documents folder or in your system folder and everything else.
Also keep this in mind: Windows loads cpu microcode updates while booting into the cpu, while macos for example only provides microcode updates via the mainboard firmware update. Those firmware updates can be prevented on macos, by removing a directory from installation / update files, but once flashed, there is no way back. This is good news for Windows (and Linux?) users, since you can remove those patches, and you will get your original microcode back (also do not update your mainboard’s firmware).
These microcode updates “fix” a lot of security holes (a.k.a. “Spectre” etc), but at the same time can heavily degrade the performance of your cpu and cpu’s gpu, too. The older your i5/i7 is, the more drastical the performance loss is. On older i7, even the virtual cores can be disabled. I don’t really know, if the average user really needs those patches. Those are all very theoretical. A NSA or a hacker group could address those holes. Still they would need access to your network or locally first. And since those microcode updates are distributed to everybody, I guess no hacker would choose an already patched hole. I even would say, those microcde updates are really bad for you and the planet, since those turn millions of running systems into garbage. They are “good” for Intel, letting you think that you need a new computer. In reality the cpu performance poorly improved since 2013 (except in really new CPUs like Apple’s one).
Live audio processing is very CPU intense, as you know. And if those patches degrade your CPU performance, and also memory accessing by 50% over a lot of patches, it is very likely to find the problem here.
As you see in the link above, microcode patches in Windows come with a KBXXX patch for Windows. Which means the files of it reside in the Windows dir and are soft-loaded. This is good news, since someone who is fit with Windows could try to remove those files from Windows in a test (and deregister it or whatever), and benchmark before and after. I did such things in Windows, but that was pre 2006… It possible for sure and not that complicated either. You might need the old version of those files. Since Windows is known for its backwards compatibility, most likely old device drivers will run in a new system. Of course you should then really disable Windows auto updater (which is possible).
Thanks so much for all these tips! I am working my way through them now. I’ve optimised everything recommended on this machine, and removed as much bloatware as possible - it seems to have helped a little, for sure.
@icepower, I didn’t know about checking the limit to stereo in/out box, but it doesn’t seem to bring the CPU percentage down at all. I am working through these other tips you sent too - so thank you. Weirdly whenever I have a tune using older 32-bit plugins it seems to have no trouble with it. I guess it’s like @rainydayshirts said earlier: I have a 10 year old CPU running many modern CPU-intensive plugins - maybe time for an upgrade, though I am strangely attached to my ancient T520 with its classic keyboard!
@ffx, this is interesting about the microcode updates, though I wouldn’t know which installed KBXXX patches to uninstall to improve CPU performance. I wonder if there is a list of particularly processor-heavy updates somewhere, and how easy it would be to nuke just those ones? And I have manual updates selected, but tend to just wave them through when they pop up. I wonder if my system would be at risk of attack if I start refusing updates?
Did you compare CPU meter when using 32 bits or 64 bits version of the same plugin? It made a difference on my computer, there is no difference on yours? Are you using a 64 bits version of Windows (I guess yes)?
Good luck on the optimization front! For me, on my older systems (I started with Renoise on a now 11 year old Alienware M17X R1 with an Intel QX9300 which launched in '08) I ultimately had to really work around my system’s limitations, which is something I generally actually enjoy. Certainly not everyone’s cup of tea, but perhaps you could rethink how and which plugins you use. Or go for the upgrade. Either way, best of luck to you!
It’s more that in the days of 32-bit plugins they were generally significantly less CPU-hungry than modern day ones. So the benefit to be had from switching out an old 32-bit plugin for its 64-bit version (assuming that was an option) would claw back a far smaller percentage than something like Vulf Compressor uses in the first place.
I’m still hoping this might appear in a future Renoise update: