Yes. When done right the asset(s) gets included in the autosave dir and packaged up with the patch. Andrew gave an example in here long time ago but otherwise probably look at the VCV Wavetable VCO code.
This is about 25MB at 48kHz, so big but not absurdly big. Definitely wouldn’t suggest trying to shove it in a JSON file, especially since you’d have to encode it as valid JSON (eg, Base64, which would blow it up by 33%). Loading the patch would probably be very slow as well. Smart of VCV to provide the capability to create other files for a patch.
Meh, I support flac in my SFZ player. All the decompression happens off the dsp thread, so the cpu hit is “fine”. Ant kind. Of compression done at load/save time shouldn’t hit the audio processing. I don’t think?
I’m not so much thinking of interference with the audio thread(s), I’m more thinking of the hit to total CPU usage of compressing 2 minutes of audio during the patch playing, and the ensuing heat generation, fan noise etc. But maybe it can be offloaded to a very low priority thread taking its time, if the audio doesn’t change often.
Oh sure, I’m not concerned about writing that data either. My concern was about adding compression into the mix, and the ensuing CPU usage. I think you should just write the .wav and not think about compression. Our challenge in Rack is not disk I/O or disk usage, but mostly CPU usage.