Sometimes, in some plugins, when GUI is opened, it slows down Renoise a lot. CPU is not utilized so much (under 10%) but everything is very sluggish and is almost impossible to craft any sound. For example - in Zebra3 beta, when I add MSEG and click to display that MSEG at the bottom, it slows down Renoise a lot. With closed instrument GUI everything works fast. And I have this problem also in PhasePlant.
Is this something I can change in Renoise to made plugin rendering different / faster?
I compared it to FL Studio and Studio One and only in Renoise I hav this problem.
I have had similar issues with newfangled’s generate. In that plugin the solution was to set it to use opengl rendering, but not every plugin has that option. Another thing I’ve found is that in cases where it does happen, only mouse-on-gui operation of parameters actually slows ui / drops input notes. Upon assigning an instrument automation slider and modifying that, everything works normally.
The problem then becomes that, according to my forum searches, people seem to have wildly unpredictable onset of this issue. Some plugins that were fine for me caused others issues and vice versa (phase plant works well here for instance). Some people seemingly solved them by disabling this or that windows service, but it didn’t work for me. Suffice to say, it’s an elusive beast and I hope if you find a resolution you share it here so there are more options to try.
Oh ok, you are not the first one reporting this problem here. I have no solution, is there an option to disable Renoise GUI hardware acceleration under Windows? Did you try that, if it makes a difference?
Well you wrote you use Windows. Either you didn’t read the news or don’t care neither for security nor performance. Also as I wrote, Zebra3 GUI is not hardware/gpu accelerated under Windows currently. The sane decision actually would be to install Linux on such a machine, just saying. And there are like 5 similar reports about Windows under Renoise. Certainly it is not the dev teams fault, but instead Microsoft turning Windows into a buggy surveillance machine. macOS is not really better, only if you really know what you are doing and disable 60% of all system services, and use a proper firewall. But Apple still has the hardware bonus, their more recent architecture is far better than x86.
I also wouldn’t be suprised if Taktik dropped Windows support alltogether.
I’m having the same issue with Serum 2. Serum 1 works fine, but as soon as animations appear in the Serum 2 GUI, the display in Renoise lags. Interestingly, this also happens when I enable sandboxing. No idea if it’s a Renoise issue or a driver problem. I’m using an NVidia card.
I’m having similar issues with ADPTR Audio Metric AB’s stereo imaging feature. It stutters heavily when I use it, and it crashes when I try to move it in the FX chain. The crash report says it’s due to issues with the GUI. I’m on an M1 MacBook.
Same here, first CR8 from Waves I reported in August 2025 and no one even cared to respond, now Pantomime 4 from Majetone, a nice freebie. Actually, CR8 has been like that for years since it has been released and no F***S were given. I guess the argument was that some moron tries to use sampler inside tracker - even if CR8 shits all over Renoise’s sampler. It’s odd that some effort was clearly put into website overhaul and marketing to make Renoise look more serious, yet it’s incompatible with the plugin (and possibly more) from one of the best-known developers, no matter what your personal opinion about them is. I don’t have to mention that it works perfectly on every other DAW on the same PC, right?
This isn’t really something that we can simply check and fix on our side. The host opens up a window for plugins and sends idle messages in some cases. Plugins then do stuff with that window which is out of control from the hosts. The only throttling we can do is sending less idle messages, but this usually isn’t a problem. So there are not many things we can tweak for plugins to work better here in combination with the host and other plugins.
Also each plugin uses different ways to do its drawing. Some may interfere with the host’s drawing. Others don’t. Some may fight with other plugin UIs resources. There’s no way to check and fix this for everyone with every plugin out there.
The only thing I can offer here is writing reports to the plugin developers, trying to nail down the problem as good as possible so they can replicate it more easily (OS version, HW specs, description on how to replicate such lags). You should do the same to make it more likely that someone will look at this.
It couldn’t be a problem if some plugin slows down every DAW. But if plugin works in FL and do not work proper in Renoise - developers will not fix anything, because this is not a problem on their side (even if it is somehow, they do not even start to investigate it).
My guess is that it might depend on which rendering API is being used. I think Renoise uses OpenGL. Xfer Serum2, where I get the slowdowns, probably does too. I also know that Nvidia’s OpenGL driver on Windows 11 isn’t great, at least for older cards. Interestingly, the slowdowns also happen when plugin sandboxing is enabled. On my Mac, though, I don’t have any issues with Renoise and Xfer Serum2.
Do you have an Nvidia card?
Too bad Renoise’s rendering engine can’t be switched to Vulkan or DirectX.
I don’t think that any rendering engine can be that slow. It’s not a 3d game after all, plugins do not draw extremely complex graphics and slowdowns are sometimes very strange, not related to graphics rendering at all.
It’s possible, whether it’s a 3D game or not doesn’t matter. It’s not about things being “slow” or rendering complex graphics, but rather that a driver bug gets triggered which causes the problem. The issue for me looks like this: Xfer Serum 2 starts stuttering badly when the UI is open and something is animated, and weirdly Renoise itself also lags, as if they’re blocking each other.
Regarding driver bugs: for example, there’s currently an issue in Reason on Windows with older NVIDIA cards. Reason uses a graphics engine that relies on OpenGL. Since around 2025, NVIDIA has been shipping an OpenGL version in their driver package that causes visual glitches in the Rack. The longer you run Reason, the worse it gets, until eventually the EXE crashes.
I reported it to the Reason team, but they couldn’t really do much right away because switching the graphics engine is a massive task.
There are workarounds though: you can disable Multi-Threading for Reason.exe in the NVIDIA Control Panel, which fixes the glitches and prevents crashes. Another solution is to drop an OpenGL wrapper into the program folder that translates Reason’s OpenGL API calls to Vulkan.
By the way, the VSTi plugin Ultra by Ultra DSP has a similar issue. It also uses OpenGL to render the UI and will crash if Multi-Threading is enabled.
