I’ve not tried these modules but just to note that in my own sampler module tests playing back a sample has very minimal minimal cpu cost. I’m running 2 instances of one stereo sampler and 1 of another at 48k with about 25 meg of samples loaded total and it shows about 25% on the cpu meter. I’m doing a 6 point spline interpolation to the samples on playback in two of the instances (since it’s phaser driven) and I’m doing no interpolation in the other (the caveat being that I’m allowing samples at the same sample rate the MM is running at and there is no speed/pitch control just a gate to play the sample or not).
There’s a lot going on in their process loop with all the (cool) resampling, interpolation, adsr etc… features that the modules have so it’s a bit tricky to know at a glance exactly what is expensive there, and obviously it’s doing a hell of a lot more than my modules, but tldr is that I don’t think sample playback per-se is that cpu intensive on the MM.
The issue to do with changing sample rates could be to do with the fact it looks like the module resamples everything in memory which is pretty expensive (and maybe uses too much ram?)
What I have seen in my own test is the issue with block sizes. At 512 I have the same issue (I’ve asked about it here Optimising sample playback routine for block size but not had a reply yet). I believe it’s a buffer filling up in the background, or since I’ve only had it happen in recent builds maybe it’s a new async call happening somewhere which is causing some issues with the audio thread. You can really tell on loops because the loop will play successfully, then sound weird, then go back to being fine at regular intervals, which definitely feels like a background process is causing the issue.