pondlife wrote:
Though, as well, a "nudge" UI (possibly even a plugin) could be made for
this specific thing to allow the simplification of the pitch and speed
settings without losing this specific way to accomplish this task.
I guess the current pitch screen could be moved to a plugin just for this
job, but I'd think that adds UI complexity. The current screen is very neat
(on a non-wheel target).
Why would the whole pitch screen need to be moved? Isn't it just the
nudge functionality that you'd need there? Pitch and speed would need to
be set in advance either way, right?
And the screen may seem "neat" to you because you know how to use it,
but two of the three screens are basically unnecessary. Is the one that
is necessary voiced well at all?
I don't understand why having them as normal lists is "bad" at all.
That makes sense, we should probably display that metric anyway (i.e.
resulting/BPM speed, not purely the timestretch % speed). The traditional
pitch change (i.e. non-timestretched) will also affect the displayed speed,
which might confuse.
In a menu, when the user changes pitch, how should Rockbox decide whether to
timestretch or not? I might have it enabled for use with spoken word, but
not want it used on musical material (wouild be pretty disastrous in the DJ
scenario!)
There are two settings, "pitch" and "speed". Rockbox doesn't decide
anything - pitch affects how the file sounds, but not how long it takes
to play (so if you adjust it up one semitone, all notes sound different,
but you still get them over the same time period) and if you change
"speed" the file completes sooner, but all notes sound the same.
Basically, timestretch is always applied (or at least, if we have an
enable/disable, it's always applied when enabled, and when disabled we
only have one setting anyway, "Pitch+Speed" or "Rate Increase" or
similar) because "Pitch" shouldn't shorten the playback time, it should
just affect the actual pitch of the sounds heard (for simplicity's sake).
In summmary, you've identified three improvements...
1) Enable timestretch by default
2) Display speed based on user's perception, not on algorithm parameter.
3) Swap pitchscreen axes on wheel targets
... but I still think the screen is needed.
And yet you've not actually described why the screen is needed beyond
"The nudge functionality should be preserved." The screen and the nudge
functionality aren't necessarily teh same thing.
