Re: Suggestion to make sharps and flats persistent

[David Kastrup]

Urs Liska <address@hidden> writes:

> Am Montag, den 18.05.2020, 18:11 +0200 schrieb David Kastrup:
>> Gianmaria Lari <address@hidden> writes:
>> 
>> > I don't know "how much Frescobaldi knows" of the lilypond code the
>> > user is editing. If it has a logical representation of the source
>> > code it could be Frescobaldi (and not lilypond) to handle this
>> > feature and offering to autocorrect, according the key signature
>> > indicated in the source code, the note you write while you write
>> > it.  You are in F, you write b and it propose bes.  Maybe with
>> > different language (never used english for lilypond note input)
>> > this would be more difficult.....
>> 
>> As an editing feature, this makes a lot more sense in my book: you
>> see the effects it has and have the means to correct them
>> immediately, like with actual graphic input.  But for a batch
>> processor, this kind of second-thinking is a recipe for trouble, and
>> the more second-thinking there is, the harder it is to reliably get
>> results without the corresponding visual feedback.
>> 
>
> I think there are only two reliable (and therefore reasonable)
> approaches. Either you encode a pitch at what it "is" (a f sharp is
> always an f sharp) or you encode it at how it is printed (a note in
> the first staff space of a treble clef is encoded as "f" and will be
> rendered as an f in c major but as an f sharp in d major. I really
> dislike this idea but it is done so for example in MEI, also Amadeus'
> input language works that way, and a power user insisted to me it is
> superior because it doesn't cause ambiguity but substantially less
> keystrokes).

It may be superior if you encode a particular graphical output.  But
LilyPond rather encodes music.  Other outputs are, for example, Midi,
and coding input in terms of the graphical representation rather than
the actual music then becomes a problem.  What if the Midi
interpretation corresponds to a different accidental convention than
what you imagine your input to be?

-- 
David Kastrup