• Users selects a drumkit file (as we do today) and clicks “Load”.
• Now the drumkit xml is loaded and the MemoryChecker analysis it so we know the estimated size of it.
• User then (optionally) turns the knob for memory preload, which live updates the estimated usage numbers in a label.
• User clicks “Initialise samples” or something like that and then the preloading starts.

While loading and while playing we could then have a label showing “current cache memory usage” which would give the users a good feeling of how much memory is used by the different drumkits.

Muldjord: I quite like how it is right now. It's simple. Click to load the kit and it will load to the specified limit. Adjust the limit and purge if you need it. Less clicks and easy to understand. I don't think this needs redesigning.

Chaot: We should probably just give a “RAM usage” knob to the users, as this will probably be the only thing they can relate to in general. Additionally we could (at least in the beginning to see if it makes sense) give some info how many samples per sound file are cached (which should also help us debug issues when they can simply tell us the value that is shown in the GUI). This shown value is of course dependent on the drumkit. Then people probably at least understand that less samples per soundfile are worse and will also with some experience understand if this value is too low such that they have to increase the RAM usage for that particular drumkit. And of course we should store this value in the drumgizmo config file.

Muldjord: A “RAM usage” knob seems like the right way to go. I would also, in combination, suggest a “purge and reload” button that simply takes the new value, purges the kit and reloads to the allowed memory limit. I think that's the two main things they use in similar products.

Deva: The “Purge and Reload” button really simplifies things from the engine perspective.

Muldjord: We could work with a colorcoded slider for setting the cache limit. We could do a simple calculation based on the kit size and look at how many instruments there are, and calculate a sanity value from that. So if the user slides the slider below a certain point, it goes from green to yellow. And even further down, turns red. To indicate that the user is now in unstable territory.

From src/drumkitloader.cc:

AudioFile *audiofile = load_queue.front();
load_queue.pop_front();
filename = audiofile->filename;
int preload_size = framesize * CHUNK_MULTIPLIER + framesize;
if(preload_size < 1024)
{
	preload_size = 1024;
}
 
// Note: Remove this line to enable diskstreaming
preload_size = ALL_SAMPLES;
 
audiofile->load(preload_size);

CHUNK_MULTIPLIER is a #define in src/audiocache.h:

#define CHUNK_MULTIPLIER 16

The loader code in src/audiocache.cc uses the macro CHUNKSIZE(framesize) for all it's chunk sizes. It is defined at the top of the same file:

#define CHUNKSIZE(x) (x * CHUNK_MULTIPLIER)

The framesize is an external parameter that is set indirectly through the setFrameSize method which again is called by DrumGizmo::setFrameSize in src/drumgizmo.cc

This call is controlled directly by the host, eg. via LV2 which can be set dynamically at runtime.

Ardour seem to use a “constant” upper limit defined byt the jack buffer size but can for a few buffer sometimes go lower than that limit. This can for example happen at the end of a loop where the loop point doesn't match the buffer size:

loop: sample 0 -> sample 2791
(sample 0) [1024 samles] [1024 samples] [743 samples] -> goto sample 0

Situations like this need special attention in the code so we don't trigger a full kit reload on such a change.

Ideally we make the code completely independent of the framesize but this will probably cost extra CPU because we constantly need to process partial buffers.

Currently the AudioCache is dependent of the framesize, so if we just change the CHUNK_MULTIPLIER (which currently is the only control parameter existing in the code) we will not get the same result if we run with different jack buffer sizes. Needless to say that this is not what we want!

The chunk size is the same size used by the inner loop of the engine which expects the call to AudioCache::open and AudioCache::next to return a buffer of exactly that size.

A design where these methods still return buffer of that size but internally contains buffers of different (larger?) sizes might work just as well. In fact this is exactly what we currently do; each AudioCache chunk is precisely 16 times the size as the inner loop buffer. However, if we need to support arbitrary buffer size we need to be able to handle framesizes that are not a multiple of the chunk size, which will might introduce a calculation overhead.

Should we decide to simply use the multiplier in the UI (which would be the fastest way to achieve our goal) then we need to make absolutely sure that the, on a size change, the inner loop doesn't receive chunks from the “old size” but are expecting the new one. If the new size is smaller we might get memory corruption.