> Okay, that's more or less what I thought. Couldn't this be accomplished
> with either pause/unpause, or my previously described method using the
> menu?

I think the timing would be much trickier, plus at least double the button
presses required. In particular pausing would interrupt the flow making it
harder to judge if you're going the right way.

> 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).

> You missed something: In my description, I said the pitch would change the
> pitch without affecting playback BPM. That means if you increase the pitch
> 25%, the song that was previously 1:30 long still takes 1:30 to play. No
> calculation necessary.

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!)

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.

pondlife
Received on 2009-06-19