> You should find that the seek buttons are adjusting the X axis, and the
> wheel the Y axis. I looked at the keymap and it seemed reasonable to me.
> Maybe the quickscreen is wrong?
The quickscreen doesn't use the wheel. It uses buttons on the wheel
aligning with left, down, and right, because the arrows point in those
directions. Scrolling the wheel left to change one setting, and right to
change another, would be even more difficult to surmise.
Also, there's nothing on the pitch screen to indicate the screen has
different modes. This can ONLY be found by trial and error or a read in
> can leave timestetch enabled all the time, but only use it when I explicitly
> want to (with no need to stop the music). Of course, the setting values
> would still interact, but this could work as long as the lists offer a high
> enough resolution (0.1% for rate, say).
If the list always had 2 or 3 options (Timestretch, Rate, or
Timestretch, Pitch, Speed) would that really be problematic?
Another option would be to have Rate, Speed, and Pitch actually be
cumulative. So a file played at 200% rate with +1 semitone and 200%
speed (on a target with a lot of beef) could be possible? Rather than
having them interact silently, that is, have them simply all work (for
the situation where timestretch is on, whether enabled or permanently)?
> Pitch and rate would need to handle semitones too (I'm not sure how).
> Speed and rate would need to support nudge (maybe some kind of
> shifted-left/right or up/down?).
I don't think "Rate" needs to handle semitones. If you want the song to
be at a different pitch, it's to play or sing along, I think. Playing
along significantly faster isn't really the same song any more. This of
course could use more feedback, but I think representing rate as a
percentage is a good idea.
I've proposed it elsewhere now, but I *really* think that the controls
in core Rockbox for this feature should focus on ease of understanding
(no hidden features like the not-hinded-at mode change) relative to the
normal UI. I think an advanced DJ plugin wouldn't be a bad idea. Plugins
have access to a lot of playback control anyway now (which could be
expanded if necessary) and this would allow even more DJ-centric
functionality to get in without any sort of discussion on binary inflation.
> Maybe we need both UIs - or maybe one for button targets and one for wheel
> targets? (I don't like that idea much, but I like it a lot more than losing
> the up/down/left/right pitch screen.)
If I thought two different UIs for different targets were acceptable,
I'd agree to this right away probably. I really don't think it is, and I
think the current pitch screen still has problems on targets that don't
have a wheel or touch slider.
There's still the obvious example of it not being immediately apparent
the screen has multiple modes. It's also not immediately apparent how to
leave it, since the majority of screens are lists you just leave by
browsing left (this is actually also a problem I have with the
quickscreen, but it's not the one under discussion here).
I just don't like that in the "core" functionality (especially one so
prominently placed as the WPS context menu) there's a screen that
requires some luck to find all the functionality in (if you don't ever
press select just out of curiosity or trying to leave, you never know).
As I said slightly above, I really think a DJ plugin could solve all
problems. It allows you to make the screen as DJ-centric as you like,
while improving the ease of use of core Rockbox, probably decreasing
binsize in the process, and dropping one more instance of "the manual is
practically necessary to use this" from the core.
Received on 2009-06-21