I don’t know if this can actually be done because of the risks of concurrent file output, but I’m going to suggest it anyway: there are very big files which can take more than two minutes to save, and for such modules autosaving backups hinders the workflow a lot. I would like this be improved by the mean of a multiprocessor approach; at present, Renoise saves the file using only one processor.
such an improvement may also be impossible for VST instruments if somehow the VST architecture prevents from doing so.
I think the action of saving a file is more diskbound than processor bound, so multiprocessing/-threading will not speed this up (in fact multiple concurrent write actions will stress the disk more and will decrease the performance…). A faster disk can solve this.
Ís the current situation such that Renoise blocks up when auto-saving a big file? If thats the case, it makes sense to do this job in the background - if not done already. Some blocking is unavoidable since that making a freeze-point of the current situation must block it for a moment to guarantee integrity of the song data…
I have disabled autosaving during play (from Preferences => Plugs/Misc => Misc) because my CPU cannot handle saving and playing at the same time, since I usually make quite high usage of the CPU.
of course Renoise must block while saving, and this is what it does.
my suggestion come by looking at the task manager while saving: in my two core system, the CPU usage was locked at 50% during saving, but you are quite probably right that a multiprocessor approach would be worst than single core, though, thanks for your observation.
just for the record, the VST I was experiencing slow saving operations, EastWest PLAY, has been updated to 1.2.0, and the saving time has dropped by a 10x factor
Would that necessarily have to be restricted to multiple cores though?
If Renoise spawned a background thread for saving (with lower priority than Renoise itself) even single core users could benefit from this. Ideally the user could chose the priority of these things themselves, so you can have inobtrusive autosaves that take ages - or quick, aggressive ones that freeze Renoise so hard the transport actually skips back a few seconds.
I don’t know if the blocking is caused by Renoise making the snapshot of the song data or that it is disk IO. I could imagine that taking a snapshot must block the song and that a worker thread is responsible for the actual writing to disk.