@jeremy I don’t think this will come up for most users but I have a habit of loading 5 minute tracks into samplers like Grains.
I noticed the “Embed Wav In Patch” option. This is great, for short samples. For long samples, writing out the loaded sample freezes the Rack GUI for a second at whenever Rack does an autosave.
I thought I was going to have to junk my laptop for not handling Rack any more until I figured this out.
Another thing is “Embed Wav In Patch” is a one-way toggle. If you turn it off, the embedded sample stays embedded.
No easy fix for either issue. Rack can’t handle auto-saving multiple megabytes of sample data without freezing the Rack GUI for a second or two, and if you toggle Embed off, and the original file isn’t there, the load will fail the next time you load the patch.
I don’t know practical embedding samples is, in the end. Sure, it’s a PITA to manage samples separate from Rack patch files, and if you only use a few seconds of audio, embedding samples isn’t a problem.
If you document when Embedding Is A Bad Idea, that might be enough. And/or warn when the user selects that option that it may interfere with the GUI performance.
It’s the collision of 2 cool things: embedding samples - yay! Easier patch sharing! - and Autosave - Boo! the mouse goes dead every so often! - and therein lies the problem.
For the one-way embedding problem the workaround is to load another instance of Grains, attach all the wires hooked to the first one, delete the first Grains, and re-load the sample file.
Documenting should be enough. I prefer embedding samples as base64 in VCV patches, and I’ll glad many modules have enabled this. I even requested this from some devs and they added this feature. So, yeah, embedding super long files might be a bad idea, but I still prefer embedding as an option.
@jeremy I was actually going to request this option for Sample Grid.
but I still prefer embedding as an option.