Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
roadmap:settings_analysis [2017/01/21 14:27] devaroadmap:settings_analysis [2017/01/23 21:55] (current) muldjord
Line 1: Line 1:
 =====Settings Analysis====== =====Settings Analysis======
 +====Suggestion: Two step drumkit load (abandoned)=====
 +  * 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.
 ====From the user perspective===== ====From the user perspective=====
-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.+//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).                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.                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.                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.                +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.
  
 ====The technical/code side of things===== ====The technical/code side of things=====
roadmap/settings_analysis.1485005229.txt.gz · Last modified: 2017/01/21 14:27 by deva
Trace:
GNU Free Documentation License 1.3
Valid CSS Driven by DokuWiki Recent changes RSS feed Valid XHTML 1.0