Hi,
these days I’m struggling to find a way to load a sample Thread-Safe (from gui) and keep safe processing on dsp (while meanwhile I can swap it).
A LIFO single-thread-safe seems a correct way on doing this on Rack, but can’t find any valid implementation on Rack tools.
For example, on WT, I see this trick, which seems a bit weird? Dunno is safe 100%.
What’s your favourite way on doing this on VCV Rack? Considering also that module can also run on headless mode, and loading sample can happens on loadjson (so not always from gui thread). Any tips?
1 Like
Best practice? That’s a big topic! Yes, you are correct that loading samples from [one of] the process audio thread is a worst practice.
First of all, the WT trick/hack. I suspect it’s safe because it is sleeping a worker thread, not the audio thread. It would not be safe to sleep the audio thread.
Yeah, as you note, doing it from the GUI is not a great idea. Yes, there is no gui at all when you are headless. Also, even if there is a gui, you maybe don’t want to load huge samples from there or you will block out all the other GUIs…
My SFZ player loads samples on a worker thread, and I communicate with the worker thread using atomic variables. I don’t have a queue or ring buffer, I dispatch the worker thread to do “a lot of work” and it reports back what it’s doing. If It’s loading all the sample in an SFZ file, that may be hundreds of large wave or flac files and it can take a long time (seconds). Also you can get runtime errors (like file not found). I need to report back loading progress and errors, so that the GUI can display that for the user.
Multi-threaded programming is not super easy, although the approach taken in VCV modules is elegantly simple.
Here’s SFZ player, fwiw:
3 Likes