TLDR: If you have a regular audio glitch, see if the autosave is disproportionally big, and check for one or more modules using a lot of room. Either get those modules to clear the data they are saving, or remove/replace the modules if possible
I was using a different PC to the one I usually use, and noted that I was getting a regular audio glitch in VCV Rack every 15 seconds. The PC is a Ryzen 3600, NVMe drive, 32GB RAM, Windows 10 Pro.
So I edited the autosave time in settings-v1.json to 60 seconds, and the glitch then occurred every 60 seconds.
I looked at the size of autosave-v1.vcv and it was 384MB. Most of this was data relating to Youlean Loudness Meter 2 Pro, which was being hosted in a Host-FX module. I removed it from the patch and the autosave size reduced to 148KB, and the audio glitch was gone.
YouLean accumulates data, providing loudness monitoring. If you don’t tell it to clear its measurements, the data it keeps continues to grow. When I added it back in to the patch, and regularly cleared its measurement data, there were no audio glitches, and the autosave was a reasonable size.
That’s an interesting point. Most VCV Rack developers should know not to put huge amounts of data into the autosave. But a hosted plugin is not subject to the same constraints, and probably wasn’t written with VCV Rack in mind.
when I started using VCV I’ve face the same issue but with an autosave file not much than a couple of kb.
But as my rack folder is located on a synchronized folder with my NAS (cloud like), each autosave occurence I saw a synch notification & get audio glitch if the patch is heavy - rack+save was not good for CPU
Setting the json as you did and sometime cutting ethernet or pausing the auto synch solved some of the glitch.
I’m afraid there’s nothing Host can do about this. It asks the hosted plugin for its state, and writes that state into the patch. If the plugin chooses to write hundreds of MB then that’s up to the plugin.
Host itself doesn’t affect playback during this process (by which I mean it doesn’t block the audio thread when asking the plugin for its state). The plugin itself might block the audio thread while providing its state - there’s nothing Host can do about that either (though it would be a pretty user-hostile thing for a plugin to do).
The act of serialising all that data will take up some machine resources, of course - CPU and disk - so on a machine that’s possibly already struggling to cope, it could cause glitching.
Sorry… no easy fix other than avoiding the situation (in this case by clearing the plugin’s stored measurements)…
I might be wrong but I vaguely seem to recall Andrew saying something like that in Rack V2 the writing of the autosave will be put into a seperate thread, which will make that issue go away.
