Closing the Redux VST causes my VST host REAPER v7.29 to freeze for several seconds. This happens because for some Reason, Redux creates several temporary files when closing the GUI and that write process is slowed down by Windows 10’s built-in anti virus software:
This is the first time I’m seeing a plugin do this. Why is it necessary and what can we do here? Switching off the anti virus software or making an exception for the temp directory are not an option.
Reaper likely stores the plugin’s current preset data here, in order to be able to undo the removal.
Redux’s preset data can be huge, as Renoise and Redux always include all sample data in their files (songs, instruments). So as long as we only allow Songs and Instrument to be self-contained, which I personally favor a lot, because that’s one thing less to worry when opening up old songs/instruments, this unfortunately is hard to avoid.
I don’t think this is true because:
%temp%/Renoise Redux-1-XXXX/Renoise Redux_TmpPath-X-X/Renoise Redux_TmpFile-X-X.tmp) is created when loading Redux in any VST2 hostLooks strongly like a plugin issue to me.
Redux stores its internal state in a temporary file before writing it to the memory buffer provided by the host. That’s where the file comes from.
Yes, it’s a plugin issue.
Why would it do that?
I somewhat had hopes that this would not happen if any unsaved changes were saved into a patch on disk but Redux always causes the main thread to stall when closing it’s GUI independently of unsaved changes being present or not.
What are the chances for this getting fixed?
This here would need to be changed:
Which currently is out of scope. Sorry.
I know it’s annoying with Redux in this case, but the fact that instruments and songs are self-contained in Renoise and Redux is in most other respects a great feature IMHO. It saves a lot of hassle when working on older projects.
I don’t understand why saving the plugin state is necessary when closing the UI. I haven’t seen any other plugin doing this. Making the plugin save its data on project save instead of closing the UI should not be out of scope.
Saving the entire sample data in the plugin state (and thus in the project file) is a separate issue. I think Redux should provide an option to only save the instrument file or a reference to the instrument file. This will keep the plugin state simple, so projects will save and load fast. Most sampler’s instrument definition files support referencing samples in a portable way. In case of a resource missing during state restore, all that users need is a dialog prompting to cancel, continue or point to a folder to search recursively for missing assets.
Should you ever start supporting the CLAP plugin format, there’s an extension that would simplify this for plugins: clap/include/clap/ext/draft/resource-directory.h at main · free-audio/clap · GitHub
It’s Reaper which requests Redux to save its state here - for whatever reason.
This indeed would be nice to have at some point.
I have no idea who it actually works in Redux, but assuming that even sample data is stored into the embedded plugin data, maybe there also could be a bottleneck when converting binary data to string/base64 encoded data or so, in the used algorithm / library itself? At least I often have this impression when loading presets. Might be total nonsense 
Or maybe the steps while saving the data could optimized, like is compression always needed…
Interesting. So far, I haven’t noticed this in any other plug-in, esp, not in plugins that tend to slow down project saving with big chunks (like loading complex Kontakt instruments). So I guess there’s more to it than simply Reaper requesting a state save when closing the Ui.
Anyway, the slowdown can be worked around by enabling the “Minimal Undo State” compatibility option in Reaper’s FX Browser for Redux.