This shows you the differences between two versions of the page.
Next revision | Previous revision | ||
roadmap:settings_analysis [2017/01/20 17:06] – created deva | roadmap:settings_analysis [2017/01/23 21:55] (current) – muldjord | ||
---|---|---|---|
Line 1: | Line 1: | ||
=====Settings Analysis====== | =====Settings Analysis====== | ||
- | From '' | + | ====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 '' | ||
<code c++> | <code c++> | ||
AudioFile *audiofile = load_queue.front(); | AudioFile *audiofile = load_queue.front(); | ||
Line 21: | Line 44: | ||
#define CHUNK_MULTIPLIER 16 | #define CHUNK_MULTIPLIER 16 | ||
</ | </ | ||
+ | |||
+ | The loader code in '' | ||
+ | <code c++> | ||
+ | #define CHUNKSIZE(x) (x * CHUNK_MULTIPLIER) | ||
+ | </ | ||
+ | |||
+ | The '' | ||
+ | |||
+ | This call is controlled directly by the host, eg. via LV2 which can be set dynamically at runtime. | ||
+ | |||
+ | Ardour seem to use a " | ||
+ | < | ||
+ | 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 '' | ||
+ | |||
+ | 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' |