I know! I have neither of those active. I don’t know what’s causing it it to crash, but I managed to make it stop by disabling the option “scan on startup” and then deleting the cache files. Then it only auto-scans my specified folder once after deleting, which is outside of Program Files.
Okay, that’s odd… maybe add a snippet of the log file
Nothing in the log helps here. It doesn’t scan Program Files when I disabled “scan on startup”. I think the fact that it auto-scans specified folders anyway had me confused. Didn’t realize that I’d still get my other plugins.
So, when is this going to be fixed? I can’t even run Renoise since 3.3 because it “hangs” on indexing Waves plugins. Do I really have to remove them from my computer for it to run?
Is there some way I could tell Renoise to NOT scan plugins at startup?
I’ve just switched off VST3 support for now:
C:\Users\Username\AppData\Roaming\Renoise\V3.3.0\Config.xml
<!--VST3-->
<UseVst3Plugs>false</UseVst3Plugs>
1 Like
Thanks!!! 
Had same problem but by removing the Waves Waveshells from the VST3 folders I could continue using other VST3 plugins.
C:\Program Files (x86)\Common Files\VST3
C:\Program Files\Common Files\VST3\
i am having the same problems with the 9.92 vst3 waveshell on mac , renoise crashes whilst scanning if its present in the system vst3 folder. If i remove the waveshell from the vst3 folder renoise completes the plugin scan and starts up.
ive disabled scanning on startup and put the vst3 waveshell back and now renoise starts up without crashing. So now i can still use vst3 in cubase as the vst3 waves works fine in cubase 11… the vst2 /au versions of waves plugins work fine in renoise anyway so i still can use them in renoise, its just the vst3 version giving it a hard time.
No need to do this, you can just use the Preferences>Plug/Misc panel.
I had to do it in the config file because Renoise would try to rescan the problematic plugin on every startup.
I’ve managed to replicate this here now with the old Waves 9 shell. It indeed eats up a ton of memory when asking the plugin if a parameter has midi mappings and never frees this memory.
I guess this simply is a bug in the old Waves shells, but as it’s unlikely that they will fix this for the already deprecated Waves 9 shells, so I’ll add a workaround in Renoise to suppress this behaviour.
5 Likes
For me it also happens with v10 waveshells, but hopefully your workaround also covers that 
Thanks!!!
Is there any downside to running plugins in that sandbox mode ? Like lesser performance or more cpu usage etc than running it in normal mode?
Probably more RAM (if you’re running several instances of the same plugin) and lack of intra-plugin communication (like iZotope or FabFilter stuff does).
What do you mean by intra plugin communication? in what way does fabfilter or izotope do that?
If you don’t know, don’t answer. The guy that wrote it is in this thread…!
It means one instance can see or influence what other is doing. For example iZotope plugins can see each others audio spectrum and you can even adjust EQ curves of plugins sitting on other tracks from Tonal Balance Control plugin.
Sorry? If everyone had this approach all threads should have OP making a question & Taktik answering and closing it.
I said “I think” because I can’t be 100% sure of the implementation in Renoise, but in Bitwig those 2 I mentioned were the - very obvious, if you have any idea of programming - consequences of sandboxing. More RAM because plugins can’t share the same assets that would otherwise be loaded and kept in memory just once. No communication between instances because that’s what sandboxing is for.
I had this and on subsequent launches a message that the waveshell crashed and will be ignored is shown, but then the Renoise main window never appears. (win 10, 3.3 64bit)
This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.