I am getting really pissed about this , just bringing up the gui of certain plugins increases the taskmanager cpu load .
My pc is an old I5 second gen , amd radeon graphics , still powerfull enough to run most plugins
Dune 3 has an initialsed preset , renoise cpu is 5 % , taskmananger shows 60 % , closing the gui brings the cpu load down
Dune loaded in loomer architect , no issues whatsoever …
All 64 bit , only happens in renoise
@gentleclockdivider. Have you tried other sounds? Maybe it’s generating some heavy sound because of the effects load. Although it is exaggerated. An i5 is already a good CPU. Have you tried changing the VSTi settings in Renoise (Compatibility Options)? Using [?] button…
@gentleclockdivider What are your gpu settings in Renoise? Do you use sandboxing? Are there some Compatibility Options enabled, like Raul mentioned? I’ve Dune 3, too. No issues here for me. I’ve a Nvidia GPU and Windows 10. What is the cpu usage of Renoise.exe in the task manager?
NO sandboxing at all .all 64 bit plugs
I am not playing any sound at all , it is an initialised preset and renoise cpu meter only shows audio load
It’s all about the gui when brought up ,and renoise exe cpu usage in taskmanager is 40 to 50%
Also win 10 here , but an old amd radeon 5700
Shot in the dark curious, does going to Renoise preferences and limiting the frame rate (say down to 20) do anything to the Renoise cpu usage in the taskmanager whilst that vst window is displayed?
Noppes
BUmping since it drives me nuts over here
It has been confirmed by the developer that this is a renoise issue .
https://forum.synapse-audio.com/viewtopic.php?f=1&t=12736
SO ?
Taktik could you please have a look ?
I could never replicate the high “idle” CPU load with Dune, but I can replicate the higher CPU usage when very quickly turning a knob in Dune.
Did a quick profiling of the fast knob mouse move in Dune. The CPU load is caused by Dune here. Below is a snippet of a the profiling.
SPluginChildWinProc is dispatching the windows events in the VST editor in Renoise (Events are mouse moves here). user32.dll is doing the Windows event stuff.
The CPU time then is mostly spend in DUNE 3.dll. Of course could be side effect of how Renoise handles VSTs, if this does not happen in other hosts, but I can’t “see” what dune is doing here, so I can’t do much here.
| Function Name | Inclusive Samples % | Exclusive Samples % | Module Name |
|---|---|---|---|
| TThirdPartyAudioPluginEditor::SPluginChildWinProc | 80.26 | 0.03 | Renoise.exe |
| TThirdPartyAudioPluginEditor::SCallPluginWindowProc | 80.23 | 0.03 | Renoise.exe |
| [user32.dll] | 80.21 | 0.03 | user32.dll |
| [DUNE 3.dll] | 80.18 | 0.03 | DUNE 3.dll |
| [DUNE 3.dll] | 80.13 | 0.00 | DUNE 3.dll |
| [lots of other calls in Dune 3.dll following…] | 80.13 | 0.00 | DUNE 3.dll |
| [user32.dll] | 0.03 | 0.03 | user32.dll |
Thanks , yes this only happens in renoise
All my other hosts , studio one , loomer architect and cockos reaper dont have this issue .
You should ask for Dune plugin dev for a fix for Renoise. I don’t want here to speak in the name of Taktik, though as far as I understood it, Renoise handles plugin GUIs different to other DAWs, because the plugins run inside the Renoise GUI/Audio engine process. So the GUI gets more sluggish/lower in framerate the higher the audio latency is. In other DAWs, the GUI and audio process are decoupled, so the GUIs framerate is independent to audio buffer. Maybe if a plugin gui process is a child of the renoise gui, it can’t be updated then more often than Renoise GUI. Some plugin GUIs might not expect that and run into a deadlock.
What happens if you set your audio latency to 2ms (or try 96khz 2ms)? Still a lot CPU for dune GUI?
@ffx If Renoise has to evolve in some way, it is in the treatment of windows for plugins. Honestly, I think it should be a priority issue, very important.
As far as I know, with Windows 10, Renoise uses Windows windows masked with Renoise’s skin. Window add-ons actually work as if they were inside a Windows window. In fact, the drop-down menu on the top Renoise bar is also a window of this style. I am not sure of all this, but “it seems that” some problems are Windows, because of this design approach of Renoise.
In fact, there is a “serious” performance problem when you use 32-bit plugins as of version 3.2.0. When you have a single 32-bit plugin window open, the top bar menu becomes excessively slow. It is unbearable! And this worsens the more 32bit windows you have open. Why does this happen?
We are talking about a drop-down menu with letters. It is nothing extraordinary that requires a lot of CPU performance. However, it works fatal. This does not happen with 64bit plugins.
What happens to the treatment of windows with Windows?
It seems that Renoise is doomed to always fail with graphic performance, when its graphical interface is tremendously light. And this is because everything is processed through the CPU, and audio is a priority. Then, the user’s visual experience will always be somewhat awkward (there will be jumps or graphic hits, always).
It is like it is. Renoise mostly is very usable. I don’t think Taktik will invest his time here, he once also explained why: Renoise core is pretty old, such things might require a fundamental rewrite of the application base.
I also don’t think it is wise to still invest any time into the 32 bit bridge. For macos, it seems to have to be removed even.
Renoise handles Plugin GUIs like any other DAW. They are not limited/bound by the audio frame rate, unless the plugin GUI itself does so.
AH ok, good to know! But clearly I have a better framerate in the VST’s GUIs within Bitwig. What is then the difference here, can you explain this to me, any idea?
SYnapse audio just realeased obession ( ob emuulation ) and sadly the cpu issue is also present , and only in renoise
Taktik , I know you can’t really do much about it but you could please reach out to richard ( synapse developer ) and get some more info on how to resolve this issue