Re: Modify fret calculation algorithm (issue3320041)

[Carl Sorensen]

On 11/27/10 2:38 AM, "David Kastrup" <address@hidden> wrote:

> Marc Hohl <address@hidden> writes:
> 
>> Am 27.11.2010 10:17, schrieb David Kastrup:
>>> address@hidden writes:
>>> 
>>>   
>>>> Yes, the assumption is that the string specification needs to be in
>>>> the same order as the note specification.  When the documentation is
>>>> done, we'll need to be sure that is mentioned.  If you specify the
>>>> notes and the strings in reverse order, it's likely to be impossible
>>>> to find frets that are close enough together to meet both notes.
>>>>     
>>> Sorry to disagree, but I see two sane approaches here.
>>> 
>>> a) when the specification is not in the required order, throw an error.
>>> b) when the specification is not in the required order, sort it.
>>> 
>>>   
>> IMHO, a) is the way to go. The source files are much more
>> readable when the input structure resembles the string specification.
> 
> I am just reacting to this keyword-triggered so I might be on the wrong
> track altogether.  Anyway: when voices cross in counterpoint, the source
> file is more readable for the purpose of following voices (logical
> order) than when sorted by string (physical order).

If voices are crossing, then the appropriate thing to do is to specify the
string on a note-by-note basis.  This is clearly allowed and encouraged.

> 
> I don't know whether we are merely talking about the open-string/note
> relation (in which case the above paragraph is off-topic at best), or
> about matching notes in the actual music to strings.

We are talking about a new syntax that facilitates entering a series of
chords that constitute parallel movement up and down the fretboard of an
instrument using the same set of strings.  And this new syntax provides a
shortcut to identifying the strings for each chord, by allowing the
definition of a string pattern that will be used for all the chords in a
run.

Thanks,

Carl