Does anybody know how many samples ahead of the argument “sample” are loaded into memory when MemoryMappedAudioFormatReader::touchSample(sample) is called? I see 64 hardcoded in the tracktion engine but I don’t understand where it is coming from.
Also I would be curious to know if somebody has experience developing sampler/looper plugins reading directly from mp3 or mp4 formats (which are not supported by MemoryMappedAudioFormatReader) with today’s SSD speeds. Any recommendations?
If you take a look at touch sample you’ll find it just uses the input stream from the memory mapped file and uses it to increase a static variable, it doesnt store the data, it just ensures the OS knows this file at this position will be used soon, after which the OS handles things in its own way.
You can mimic this behavior very easily when packing things in monoliths, but this doesnt help you read parts of the file in any special way. To do that you need a codec that supports direct access, or block based access - this is a deep subject but you can check out the BFDLAC talk on the JUCE channel if you wanted to get inspiration and go that route.
This is overkill for just a few samples though, if you’re playing just a few samples you can use mp3, flac or whatever, and just store either the whole file or part of the file in RAM to read later and start reading into another buffer while youre grtting through the preload (or a circular buffer if you fancy it).