From: Paul Louden <paulthenerd_at_gmail.com>
Date: Fri, 19 Jun 2009 09:48:57 -0500

pondlife wrote:
>> I'm not entirely sure what you mean by this. Could you explain a little
>> more?
>>
>
> Sure - the only reason that Timestretch can be enabled/disabled is to save
> on RAM. This is basically the same reason we allow configurable limits for
> "Max entries in file browser", "Max playlist size", plus give options for
> "Directory cache" and "Database - Load to RAM". In an ideal world with lots
> of RAM you'd happily set the maximum limits and enable all these features.
> However we allow users to disable functionality they don't particularly want
> and so gain some battery life.
>

Ah yes. I see what you mean. I'd consider "timestretch" a bit different
simply because not only do you enable timestretch, but once it's enabled
it adds another option in a place you may not expect an option, having
already explored it before (which is the main part of the behaviour I
don't like. If I could get it reduced to menus, the on/off might not be
such an issue for me).

These other options, I understand. It might make sense to group them all
somewhere.

>
>
>> To be honest, I may have a poor understanding of "nudge" in the first
>> place. Could you explain exactly what nudge is for?
>>
>
> OK, say you are monitoring (through headphones) a proposed "new" track which
> you want to beatmatch with some other music (i.e. played on another DAP, or
> even a CD) which is currently playing to all and sundry. You can use the
> pitch shift to get the basic BPM right, or close enough, but you then need
> to get the start of a bar lined up so you can mix the new track in smoothly.
> By holding the left/right buttons, a temporary +/- 2% pitch shift is
> applied, allowing you to "slide" the new track relative to the current one.
>
> I hope that makes some sense, I'm not great at explanations without arm
> waving.
>

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

>
>> Calculate the corresponding percentage for what, exactly? And why wouldn't
>> you need to calculate a percentage with the old system? I can't understand
>> what you're trying to do, here, that requires calculations but didn't
>> previously.
>>
>
> Say you want to change the pitch of a track to match your piano tuning, but
> you want to maintain the exact same BPM. By increasing the pitch by 25%
> (i.e. increasing to 125%), you'll also increase the BPM by 25%. To get back
> to the original BPM, you'd need to reduce the speed to 80% (100/125 = 0.8).
>

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.

> If you go into the Timestretch mode in the current pitch screen, as you
> change the pitch, the speed is automatically recalculated tro maintain the
> original BPM - you'll see it displaying Pitch: 125% Speed: 80%.
>

Yes. That speed value is meaningless to a user since the song is
actually still playing at 100% speed, with the user hearing notes that
are at 125% pitch, but at the same timing and duration (which is "speed"
to the casual user).

>
>> I assure you, it's basically the least intuitive screen on the iPod at the
>> moment, and it's not something easy to resolve by keymap alone. The screen
>> layout just doesn't work for it. But I think if you could explain,
>> exactly, what uses you have a menu layout may not be as bad as you think.
>>
>
> I guess the basic problem here is that the pitch screen is fundamentally
> based on 2 dimensional input (UP/DOWN/LEFT/RIGHT) but a scrollwheel offers 1
> dimensional input (CLOCKWISE/ANTICLOCKWISE).
>
> Perhaps the two axes are the opposite of what you'd expect - i.e. we should
> have pitch on the wheel and speed/nudge on buttons?
>
>
It's less that, and more the fact that it displays things like the
quickscreen, but works completely differently, and the
up/down/left/right arrows don't really correspond at all. There's not
really a way to match it without reorganizing the screen for wheel
targets, and I just still am not convinced that screen is at all necessary.
Received on 2009-06-19