> My understanding was that it cost 64k of RAM. That's not terribly > significant. It's not small, but for avoiding user confusion (forcing them > to look in two places, and reboot, to use a single setting, which > basically means the manual is required for them to figure this one out) > it's probably worth it. And isn't Pitch still adjustable with it on?
Maybe we should put all of the "RAM saving" options together under System > Limits and enable Timestretch by default? > With a normal menu that updates live, this can be accomplished. Set the > value to 120% speed. Then move to 122% and when the beat matches cancel > out of the screen, immediately restoring it to 120%. The current UI nudges the pitch up/down only while you hold a the key down, making it really easy to use. I really can't see that a menu UI would work so well. > If you need speed and pitch both changed, you just change both of them. You'd need to calculate the corresponding percentage, and you can't adjust both parameters at the same time (e.g.. you'd increase pitch, then decrease speed, rather than doing both at exactly the same time as you currently can) > "What you want when you're DJing" does not necessarily equate to "what > makes it easiest for users to understand and use." You don't actually lose > any functionality doing it as a proper menu, you free up some RAM from the > custom screen (possibly even significantly mitigating the cost of making > it always on, though that's unnecessary for this) and you make it much > easier for users to understand how to use, as well as being easier to use > on more targets. I agree that we should be making it easier to use, but I disagree strongly that a menu would make for a easier-to-use UI here. (I can only speak for button-based use, I've no experience with Rockbox on a scrollwheel or touchscreen - that might be very relevant to our disagreement.) Certainly, defaulting to having Timestretch enabled would improve usability, but I don't know if other developers would accept the RAM impact (when discussed on IRC way back when, it seemed timestretch wouldn't be acceptable for committing if it gave a compulsory RAM loss). pondlife
