I spent some time playing with Bidoo cANARd and Sickozell sickoSampler. Very cool to have sample recording and playback on the MM!
At first I naively tried loading an audio file with a sample rate of 44.1 kHz, and it very quickly crashed the Meta – sometimes when trying to load the sample (cANARd) and sometimes when trying to switch samples (sickoSampler).
When I converted the samples to 48 kHz they worked much better, so that’s great. But this is still not a great situation, for a couple reasons:
There’s no documentation that I can find around the MM’s own internal sample rate, let alone anything about the sample rates of wav files. I’ve spent a lot of time reading this board, so I had a hunch for what the problem might be, but that’s not something to expect from a user.
Loading an incompatible sample has a very bad consequence — it doesn’t just throw up an error message, it crashes the entire device.
And crashes on the MM are extremely costly, because:
they require the user to restart the module, which takes a long time;
they might result in a different set of plugins being loaded after the crash, which adds friction;
they require the user to power-cycle their entire Eurorack case, which might include other modules that don’t save state on restart.
So my request is:
a fix for the mismatched-sample-rate issue, even if that fix is “The Meta Module won’t attempt to load files with inappropriate sample rates and displays a dialog saying so, independent of any individual module’s loading process”;
more crash resilience, including if possible a way to restart the MM from a crash without power-cycling the case and a way to preserve plugin load state when restarting from a crash.
i put in a request for ‘easy restart’… hopefully we see something like it in mm! or otherwise more stable sampler capabilities on mm
for now i just keep the mm unscrewed (unless travelling w it) so i can pull it out a bit and hit the manual reset button that lives on the underside of it, top right of the 4ms logo
when i first started heavily testing with sample loops a few months back, i had a lot of problems with 44/16. so i just run a batch conversion (reaper) to keep everything at 48/16. i always keep my mm set to 48.
i avoid sickocell/voxglitch samplers - their modules hav a lot of ram bloat. sickcell ones cut off your sample at 30seconds max. if you want to run longer samples, canard is the way for now. after doing a ton of tests to find the length limits before ram crashes, here are my numbers:
12x instances of canard in a patch: all 48/16 samples must be at 40s or below
8x: 70s or below
6x: 87s
4x: 95s
1x: 140s
those tests used patches that required only the following plugins to be loaded in at startup (about 13mb ram used at startup):
bidoo, fundamental, bog, mshack
weirdly the 8x gives the longest total run time: 560s/9.3m sample length in total.. but im finding that 6x instances works best overall w mm - 6 knobs on mm for trig+vol of each, and the 6 remaining knobs to control speed, etc.
anyway the only crash i’m getting now is related to the issue mentioned below (1st patch always loads fine, but 2nd patch after that might crash):
my remedy: when i need to switch to the next patch (and avoid the potential crash), i lift the mm out of the case a bit and hit that reset button then load the next patch. not pretty on stage, but works.
Got it, thanks! I am working with much shorter samples so I will keep playing with Sicko and Voxglitch too. Hopefully Dan can squash the cANARd bugs, and also put in a warning about 44.1kHz samples.
If anyone’s following this thread: I’ve converted all my samples using the the afconvert command-line tool on macOS.
Yeah, the sample players available at the moment currently have some limitations. Some of them have some serious issues making them unstable. I think the basic cause of this is that on a desktop computer a plugin module can get away with a more loose use of memory and nothing really bad happens (the OS cleans it up when you quit VCV Rack), but on a small embedded system the code needs to be very strict about how it handles memory (there’s no OS to clean up for you).
We just found a memory leak in the Sickosampler, and @sickozell is working on that as well as some other memory handling improvements. The Bidoo canard has some problems with how it’s using AsyncThreads.
I didn’t know about canard needing certain sample rates, maybe @etcetc can answer? Having a message like that pop up would be great. It would have to be built into the sampler module, not the MetaModule firmware (the MetaModule has no way to know what the plugin is doing).
What I can do on the firmware side to support that is provide a way for plugins to send notifications (this has been requested recently).
Your other request about crash-resilience is right on. I’m working on making it kill the audio so you can at least try a different patch/sample.
But really – I think on the MetaModule it’s better to stream than to pre-load large samples into RAM. Streaming from disk into a buffer lets you play large sample files without huge loading times, and it puts less memory pressure on the system (less allocations and de-allocations so less fragmentation). So where I want to place my focus is on the STSD, not so much on fixing 3rd party plugins. Maybe once the STSD is established we can back-port the streaming system to other modules since there’s bound to be differences in features and workflows.
Yeah, that makes sense — have a canonical 4ms-approved way to do sampling that you can vouch for, and not try to be responsible for every single port. Godspeed!
I’m pushing an update to Bidoo 2.0.1 to try and resolve this. I seem to be able to load a 44.1khz sample without. crashing, but not sure if it was random before.
Bidoo 2.0.1 : just loaded my template (6x canard w 80s 48/16 wav) set of patches: 01.yml straight to 64. no crashes along the way. TY etcetc!! and dan, again for the faster load times!
will report if i run across anything else… but seems to be pretty darn stable so far.
I use the Sickolooper a lot — it would be great if, when saving the MM file (on the MetaModule), it could also store the sample locations.
Right now, every time I want to load a patch, I first have to export the samples on the MetaModule, and then, when I open the .yml file, I also need to manually load the save file on the Sickolooper. It would be great if the MM file could store the sample locations, so everything loads in one go