> Use of Replaygain has an impact on battery life IIRC. Might be better to
> merge the "Enable replaygain" option into the "Replaygain type" menu as an
> "Off" option. (This would default to Track gan if shuffling", giving one
> less menu ioption and the desired default behaviour.)
It shouldn't have an effect on battery life if the files don't have
replaygain tags, and IIUC the effect is incredibly minimal.
>> To me the most "obvious" improvement would be to drop the toggle for time
>> stretch (despite RAM cost, this is the sort of feature that should be
>> always on
> I disagree - with the current algoithm the RAM cost is significant, and the
> impact timestretch has on sound quality (e.g. mono output and plenty of
> artifacts) mean that in many cases (i.e. non-speech) it's better to use the
> old pitch-only option.
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?
>> and reduce it to a menu with two options ...
> I'm strongly agains this - it removes two key features of the pitch screen:
> - beatmatching (the +/- 2% shift)
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%. In fact, this could
even give you finer control over beat matching than you have currently.
> - the ability to change pitch without changing BPM/perceived speed (i.e.
> where speed and pitch change together)
How would this remove that? I said two settings, "Pitch" (which would
change pitch without changing BPM) and "Speed" (which would change BPM
without changing pitch). If you need speed and pitch both changed, you
just change both of them.
> Plus, the pitch/speed values are not settings - they are not persisted.
They could (and possibly should) be.
> This, along with the above, is exactly what I want when I'm DJing.
"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.
Received on 2009-06-19