This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
roadmap:settings_analysis [2017/01/20 17:26] – deva | roadmap:settings_analysis [2017/01/23 21:55] (current) – muldjord | ||
---|---|---|---|
Line 1: | Line 1: | ||
=====Settings Analysis====== | =====Settings Analysis====== | ||
+ | ====Suggestion: | ||
+ | * Users selects a drumkit file (as we do today) and clicks " | ||
+ | * 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 " | ||
+ | |||
+ | While loading and while playing we could then have a label showing " | ||
+ | |||
+ | 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. | ||
+ | ====From the user perspective===== | ||
+ | //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. | ||
+ | |||
+ | // | ||
+ | |||
+ | //Deva:// The "Purge and Reload" | ||
+ | |||
+ | // | ||
+ | |||
+ | ====The technical/ | ||
From '' | From '' | ||
<code c++> | <code c++> | ||
Line 42: | Line 65: | ||
Currently the AudioCache is dependent of the framesize, so if we just change the '' | Currently the AudioCache is dependent of the framesize, so if we just change the '' | ||
+ | |||
+ | The chunk size is the same size used by the inner loop of the engine which expects the call to '' | ||
+ | |||
+ | 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' |