The ~ symbol in the menu shortcut indicates that this function is provided by a tool, and is probably not a part of native Renoise.
Can you check which tools you have installed?
Here’s what I see from a stock install:
2 Likes
Yes, sorry I had double tool installed.
I had midi convert from Dac Chartrand… doubled…
Korg M1 v2.4.1.0 VST3 and Korg Wavestation v2.4.2.0 VST3 graphical interfaces still do not open in Renoise 3.4.3.
Unfortunately I could not find a workaround for this. These plugins do something with the host windows that other plugins don’t. I’m in contact with Korg to get this fixed, but unfortunately it won’t make it into this release.
1 Like
Thank for your reply taktik,
FYI: Korg Wavestate v1.1.1 VST3 however does open the graphical interface correctly in Renoise 3.4.3.
Would it be possible to add a keyboard shortcut for HIDPI scaling in this beta?
Plugins need to be reloaded to apply DPI setting changes, so a shortcut unfortunately won’t really help here.
3 Likes
w007! 
GREAT to finally hear from you Taktik! 🫶🏻
4 Likes
OMG OMG OMG!!! Great to hear from Taktik and great to know that we are being heard. This is awesome
4 Likes
Thanks heaps for the update! I’ve had some ongoing issues with plugin interfaces - some listed on the changelog - really appreciate these being addressed! Long live Renoise!
1 Like
Anything new on the u-he synths bug where the multicore setting is not saved and will reset to the original position each time the project is loaded? Reported at least three years ago
Could you give us a few more hints/details on that?
There’s a multicore button on u-he synths like diva and repro, when you press it, the cpu load is way lower, but it is not saved in renoise (on presonus studio one 5 it saves and you would expect) , so each time you open the project, the button is unpressed and you have to go through all instances of u-he synths to enable it
If that’s true, then it’s more or less random if this option gets applied or not. This then should be fixed by UHe.
Based on my testing before this is still exactly the problem. It is a very shoddy choice on U-he’s part to try to rely on non-standardized implementation specific behavior like that, assuming that preset data is loaded immediately after the plugin has been initialized by the host. My assumption is that Renoise instead loads and initializes all plugins in bulk first (which can take quite a while), and then afterwards applies all patches in bulk, meaning that the duration between initialization and patch loading is often much more than one second with any non-trivial project.
Assuming this is the case, the only fix on Renoise’s side would be to overhaul the project loading behavior and instead presumably do what other hosts do. But it’s kind of a silly thing to ask because U-he definitely shouldn’t rely on the internal architecture of the host to have correct behavior. Unfortunately we’ll probably have hard time convincing them to find some other way or to make an exception for Renoise… 
1 Like
Nice!!!
cannot reproduce it on mac though
Oh ok, I’ll bug u-he about it, I hope they do something about it, it’s super annoying especially if you have a heavy project and you get a dropout.
Other thing, is there a specific reason why an effect container can’t be dropped on a track until a plugin has fully loaded? When you try to add any heavier plugin, you will have to dangle the effect over the track for several seconds until it has completed loading, and only then you can let go of the mouse. Also double clicking to add a plugin often does not work with heavier plugins. It feels like if you could drop the effect container separately from the actual loading, it would be a much smoother experience. You could drag the effects on the track much faster, especially when adding several.
From what testing I have managed to do with Redux in Bitwig. 1.3.3 seems to be working as expected now. Thanks for your efforts.