[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Carl Sorensen
Subject: Re: Fix determine-frets so that it preserves note order (issue4518045)
Date: Mon, 9 May 2011 12:44:52 -0600

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

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

In absolute mode I can write a C major chord as

<c' e' g'>


<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

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!


> Cheers,
> Neil

reply via email to

[Prev in Thread] Current Thread [Next in Thread]