I’m taking a gamble in guessing that what makes large projects time-consuming to save is gathering/compiling/distilling VST and VSTi plugin data/contents for each plugin used in a project. There seems to be a lot of anecdotal evidence this is the case: after triggering File → Save, Cubase I assume polls each plugin sequentially for its state/settings/data (including samplers like Kontakt and all of the patches contained within which can be quite large). Most of my sessions can take 5-10 seconds to save, even on a high-powered Mac Pro with an SSD.
Here’s my thought: Could Cubase/Nuendo have a background thread set to a priority lower than the audio engine be set up to keep that “distilled” copy of each plugin’s contents/data cached in memory as the user works on a project? ie: periodically poll each plugin in a project and see if the thread’s cache of that plugin data is different, or be triggered to update its cache when only when the plugin’s state is dirty (ie: a parameter changes within a plugin). In theory it would take up no more additional RAM than what the file would take up when saved on disk.
Then, in theory, then when a user triggers File → Save, all Cubase has to do is write all that cache data to disk which should be near instantaneous because all the heavy lifting has been done behind the scenes prior.
Coming from a coding/programming background myself, I’m wondering if the Steinberg engineers think they can implement this, as I know in theory it’s possible.
Where I see this might be a challenge is if there is no reliable way via the VST API/SDK to ascertain a plugin’s dirty state. Then there’s no way to know whether a plugin’s contents have changed. And in that case, this whole suggestion is moot as Cubase would have to poll each plugin upon File → Save any way.