I would like to be able to load the 32-bit AND the 64-bit version of some of these plugins – for instance, Kore 2 didn’t come with a bit bridge and now the 64-bit update only loads 64-bit plugins. I would prefer the option to be able to run the 32-bit Kore in x64 Renoise for the few plugins that are not yet updated with x64 versions, in addition to the updated x64 version. REAPER, for instance, offers me a choice of x64 or 32-bit in case I need to run one or the other, or both. Since there is a sandbox option to run all plugins in separate processes, shouldn’t it be possible to enable 32- AND 64-bit versions of the same plugins, regardless of which version of Renoise is being run? Or, add an option to hide redundant versions if users prefer to hide the deprecated 32-bit plugins that have been updated to x64.
For what it’s worth, I also tried renaming and copying the Kore 2 32-bit dll’s to see if it would catch a difference in name change, but it made no difference. Only the x64 version shows up. (edit: I am running Windows 7 x64)
It is possible! Are you sure you have set up a VST path to the 32bit versions? As they will reside in a different place to the 64bit version. Or is it only if you have both installed it will only list the native version for some reason? If so what benefit would there be to running the non-native version of exactly the same plug-in if you have both installed?
Yes, but when both versions, a 32bit and a 64bit version of the plugin is present, Renoise will always prefer the “native” one (32 bit plug in a 32 bit Renoise, 64 bit plug in a 64 bit Renoise) to avoid any overhead or “compatibility problems”.
I can see that this can be a problem in Kore, but you probably should then stick with the 32bit version. Alternatively, delete the 64bit version of Kore, then Renoise will always use the 32bit version.
So there’s no way to enable Renoise to show “non-native” versions as well? If not, can I post this as a feature request?
That is a bummer. It would definitely entirely defeat the point of the x64 Kore if I give it up since it does make a difference in performance. Given that I’ve been waiting for this update for a while, I’d like the advantage of faster performance. It’s not Kore’s fault, it’s actually the fault of other plugins that haven’t been developed as 64-bit yet. I was hoping for an extra workaround in the meantime
Kore 2 32-bit doesn’t load x64 plugins. I would like to be able to use those plugins in 64-bit Renoise using Kore. Kore 2 x64 does not load 32-bit plugins. Of course, now it is discontinued, so what I’m asking for is pretty much useless, but I thought I would give it a shot. Thanks!
Never used Kore but having a look at it I can see exactly why you may need both for this type of program. Thank you for taking the time to explain to me.
Would it be best to enable loading of both for all plugins you have 32 and 64 bit versions of? Or an exceptions list (which would hopefully remain quite small)? Or maybe a right-click → load non-native bitrate version for plugs that have both? The last way would be almost invisible to the user unless you looked for it.
It might be. I wouldn’t have a problem with that, anyway. REAPER does this by default (in 32- and 64- bit).
I wouldn’t necessarily have a problem with this, either, but I assume that would be asking the user to choose manually which plugins to load non-native versions of? That’s slightly tedious, but only a one-time procedure.
That might be difficult and/or confusing since it would essentially be “hidden.” I was actually thinking to put the option “Allow non-native plugin instances” or something of the sort right next to the option to load them all in separate processes. That way even 32-bit users will have access to both plugin versions, and hopefully if there are compatibility issues, running plugins in sandboxes should prevent a global crash.
Here is a mockup of what I was thinking it could look like:
2777
