On Tue, Jul 14, 2009 at 8:24 AM, Al Le<al.le_at_gmx.de> wrote:
> Yes, that was the idea -- have just table based semitones (in 0.5 semitone
> steps, i.e. 49 entries in the table). And even (maybe) drop the
> interpolation. I.e. when switching from procentual to semitone mode, the
> next semitone-based value would be set.
Hmmm, yes, I suppose that would knock out some of the code bloat.
Regarding the question of semitone precision, yes, a western musician
would generally think in whole semitones, but not all music follows
the western standard of twelve notes per octave. Furthermore, what I
imagine using the smaller-than-semitone adjustment for is mostly to
match pitches between two recordings or between a recording and a live
performance. In that case, musicians will quite definitely hear the
difference between .5 and .1 precision. Even with .1 (and this is why
I was concerned about super-anal musicians) the notes will sound very
close but you'll get interference beats when it's not right on (which
can sound pretty horrendous). Going down to cents is really the way
to avoid that problem. I didn't go that far in my implementation
because it would have been a pain to cycle through the semitones one
cent at a time. I still would have liked to maintain 1-cent precision
but I couldn't think of a good interface for it.
As for switching over to procentual mode for more precision, yes, that
seems like a possibility, but it also seems like a counter-intuitive
pain in the butt. Musicians think in semitones, not percent. I feel
that maintaining the semitone precision is worth the size increase --
at least for people who use the pitch screen. I suppose that's part
of the issue here: how many users will ever use the pitch screen?
So, to sum up: to a musician, higher semitone precision is Good.
> What *would* be very useful though is the ability to toggle the modes in the
> opposite direction -- to be able to directly switch between procentual and
> semitone mode while staying in timestretch mode.
Absolutely. Not sure how to do it without using another button, though.
>> Those >> and << labels always seemed superfluous to me, for
> They are not very useful, agreed, but they do no harm too (at least with
> regard to the binary size)
Well, they add a couple more conditionals, a couple calls to sprintf,
and a couple string constants that have to be stored in the binary....
Received on 2009-07-15