What do you do to keep your Renoise CPU low? (Windows)

Hi there

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.

Thank you!

Are you using cpu intensive plugins? Working primarily with renoise native synths and fx saves a lot of cpu. resampling loops/voices/patterns is your friend as well

1 Like

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.

What is your PC specs? Especially cpu and ram

Do you use ASIO driver and what is your buffersize?

From their article you should be able to have 1024 which gives you an annoyingly high latency but at least you should be able to finish up your song.

1 Like

You can also render out the chunks/samples with the busiest processing when you know you won’t change it much. Offloading those THICC fx chains like that helps a lot in my experience.

Edit: If you’re using tons of sample based instruments like me, using VST aliases reduced my system load by ~0.3% per alias compared to single instantiations. It add up quickly. :wink:

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.

Capture

10 year old CPU running many modern CPU intensive plugins… I think I found your problem.

If you have already gone down the rabbit hole of optimizing WIn7 for audio (google that if you haven’t), you may be at the end of the road on this front considering hardware limitations.

I’d circle back to the recommendations in this thread.

1 Like

Agree with Jesse that your CPU is not capable, i have a fairly new i5-9600k desktop CPU with speedy 6 cores and still have to run 1024 buffer size to finish my songs.

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.

1 Like

A couple more suggestions:

  • Replace 32 bits plugins by 64 bits version
  • Use send tracks to avoid duplicating effects (I guess you are already doing this)
  • Check the Limit to stereo in/out box in audio options
  • Check the Auto suspend plugin when silent in each plugin options (check if it causes troubles with you plugins)
  • In the plugins: check if you can reduce the number of voices (polyphony), disable oversampling if any, disable internal effect, etc.
  • In the Windows device manager disable what you don’t need (e.g. Wifi card if you use a network cable)

And of course if not already done search for Windows optimizations tips (most of Windows 10 tips apply to windows 7 as well), e.g. this: https://support.focusrite.com/hc/en-gb/articles/207355205-Optimising-your-PC-for-Audio-on-Windows-10

1 Like

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).

1 Like

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?

1 Like

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!

1 Like

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: