> Yes, and it's quite hard to use (and goes contrary to established > expectations from the quickscreen) on several targets in a way that can't > be effectively addressed without changing at least how the screen is > displayed.
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? > This is based on the assumption that you're keeping the pitchscreen how it > is, rather than moving it to lists. You can navigate up and down lists > fairly quickly on wheel targets, and most non-wheel targets have a page > up/down as well as accelerated scrolling, so a moderately fine grained > semitone-based list works for both of these. How about having a list with 1 OR 3 entries - i.e. rate (always displayed), pitch and speed (only displayed when timestretch is enabled)? That way I 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). 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?). 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.) pondlife
