Re: Accidentals: Unwanted naturals

[Joseph Wakeling]

Kieren MacMillan wrote:
> Hi David R,
> 
>> AFAIK, all of the graphical-interface music scoring programs
>> use the visually-oriented logic.
> 
> The last time I used Finale — which, thankfully, was a very long time
> ago! ;) — there were only two ways of entering notes:
> 
> 1. From a MIDI keyboard: Clearly, you can't "follow the key signature"
> with this method, since pressing a (MIDI) g-sharp gives a g-sharp,
> regardless of the key signature.
> 2. Mouse/QWERTY keyboard ("Speedy"?) entry: When you clicked on (e.g.)
> the "g-line" of the treble clef, a g-NATURAL appeared, regardless of the
> key signature, and you had to scroll up or down (or click-add an
> accidental) to change the pitch/alteration.
> 
> Is that not still true? Are there any Finale or Sibelius users out there
> who can confirm what model these prorgrams use?

The discussion is heading in some unfortunate directions because of a
confusion between data entry -- which is a matter of the user interface
-- and the underlying data _structures_, which are something else.

In the current version of Finale, and all that I can remember, note
entry does indeed 'follow the key signature': if I use the so-called
'speedy entry' mode in a score with a key signature of Bb major and
place a note on the middle line of a staff with treble clef, Finale will
interpret the entered note as being a Bb.

Now, if I try to change the key signature, Finale presents me with
multiple options: transpose the notes to the new key; preserve the notes
enharmonically; preserve the notes chromatically; or preserve the notes
_modally_ -- that is, maintain the staff positions but interpret the
notes in the light of the new key signature.  (So, if I changed the key
from Bb major to C major with this last option, all the Bb's and Eb's
would change to B- and E-naturals.)  Essentially, I'm being asked if I
want to preserve the underlying data or to rewrite it according to one
of various different rules.

What's implicit in this is that Finale's data structures, like
Lilypond's, store the exact notes -- but Finale's _user interface_
permits a data entry method that simplifies the process of entering
tonal music, along with a number of macros to rewrite the underlying
data in different ways when key signatures are changed.

On the other hand if you're writing Lilypond code using a text editor,
you're writing straight to the underlying data structures used to
generate the score -- and it would be insane to distort this with
'follow the key signature' rules, because it introduces all sorts of
recursive dependencies and potential sources of error.

Features like Finale's can easily be developed for GUI front-ends like
Denemo and even potentially as macros for a Lilypond editing suite like
Frescobaldi, but to introduce them _at the data structure level_ would
be a very big mistake.

    -- Joe