R3.2.2 or old, W10
Renoise: Preferences / Plugin / Misc there is the following option:
Run all plugins in sandboxes (-->separate process)
- If this option is activated, all plugins, both 32bit and 64bit will run in a separate window.
- If this option is disabled, only 32bit plugins will run in a separate window.
In either case, running a separate window (both AudioPluginServer32.exe and AudioPluginServer64.exe) causes a general slowdown in the Renoise GUI. That is, any 32bit or 64bit window run separately is going to negatively influence the graphics performance of the Renoise window. Why does this happen? Is it a direct Windows 10 problem or is the problem really internal to Renoise?
One very clear way of looking at it is to navigate through the Renoise top bar menus when Renoise are running any AudioPluginServer32.exe or AudioPluginServer64.exe (you must have the plugin window open). You will see that it works as if it were drunk. And furthermore, the problem is cumulative. If you open multiple plugin windows, the Renoise GUI will perform even worse, especially in the drop down menus…
I think this issue is one of the main current problems for Renoise, from that Renoise reached the first version with HiDPI compatibility.
Renoise Team, could you please resolve this matter?
I use this option as a failsafe, because it it prevents any one VST thingie from crashing Renoise. The VST will crash and stop working, but It’ll allow me to save and restart without loosing time/data.
Yes, but this “safe option” should not affect the graphical performance of the main Renoise window, so that we can use this safe option in complete comfort.
For example, it is not possible to use the Renoise top dropdown menu correctly if you have multiple plugin windows open. It’s a notable performance failure!
I come back to this thread to confirm it. Even with Windows 11 and R3.4.2 the above is still a noticeable graphics performance issue. In fact, it not only affects Renoise dropdowns, but also noticeably slows down important window tools.
It seems that Renoise has a clear problem trying to control separate windows, at least on Windows.
@Raul I see that you are using 32 bit bridge, too? Mmh, I thought that 32 bit was removed in 3.42? Did you test it with 3.42? Does this happen with only using 64 bit bridged, too?
I just tried with only 64bit versions and high perf profile in Win10 and R3.4.2 with the same results. If I have more than 3-4 windows open (4K screen) it gets really sluggish.
Yes. I have tested this issue with all the latest versions of Renoise and it works the same, with the same lag, even the latest version 3.4.2.
It doesn’t matter if the plugin is 32 or 64 bit, the behavior is the same. The issue is whether to use a separate window (sandboxes enabled), not whether the plugin is bridged or not.
I know this affects 2 cases that are directly related:
- Renoise dropdown menus. If you have several plugins open and visible, the dropdown menus are a mess.
- Window tools with moving objects. The same thing happens as in case 1. Anything that moves in the window, including tooltips or moving objects, slows down and is very noticeable.
However, I just retested case 2 and it now works fine with sandboxing enabled (tested with 5 plugins with windows open, all ok). This matter has me puzzled. The only changes that my PC has undergone are a power off and on and also a Windows 11 cumulative update. I do not rule out that in case 2 the operating system may also have an influence.
But there is still case 1 of dropdowns, which always works badly. What is going very slow is “the act of detecting and opening the dropdown”.
I have the same issue with bridged plguins on macos, but only with some specific plugins. So here, it also seems to be dependent on the plugins’ code… Do you have a similar experience? Or is it all the time on Windows?
I’m just testing it with Windows.
What I don’t understand is: why does this affect Renoise dropdowns and maybe the Renoise API (window GUI with moving objects) as well, if it’s running a plugin in a separate window. My computer has plenty of power to move all this with ease.
Regarding 4k, it is reasonable to think that a powerful computer is necessary, with a graphics card that can move that high resolution with ease, in addition to the CPU itself.
Probably just need to stick a couple mw-update() statements into the ‘sandbox’ function.