Re: Fix determine-frets so that it preserves note order (issue4518045)

[Carl Sorensen]

On 5/9/11 12:34 PM, "address@hidden" <address@hidden> wrote:

> Hi Carl,
> 
> LGTM, apart from some indentation issues.
> 
> One question for you though: do you think the refactoring is an
> improvement on the current code?  You could for example achieve the same
> result with the following:
> 
>      (sort string-fret-fingering-tuples
>           (lambda (a b) (> (car a) (car b)))))
>      ;; end of determine-frets-and-strings
> 

There's no guarantee that the notes will be in decreasing string number
order.

That's the general case, but it's not required.

In absolute mode I can write a C major chord as

<c' e' g'>

or

<g' e' c'>

and as far as I know, we have no requirement that we write chords with the
lowest note first.

Originally, (before the harmonic became part of the tab note head) we could
be order-agnostic, because each head had its own information necessary to
place the glyph.  But now we aren't order agnostic because of glissandos on
each note, and because the harmonic needs to be associated with the proper
note.

Additionally, there are instruments (at least one, the ukulele) where
strings do not increase in pitch, so pitch order (as chords are generally
entered in relative mode) doesn't necessarily match string order (which is
what the sort call you proposed creates).

For these reasons, I think something like what I've done is better than just
the sort code you proposed.

But I'm open to having the discussion.  Thanks for the feedback!

Carl



> Cheers,
> Neil
> 
> 
> 
> http://codereview.appspot.com/4518045/