Re: Suggestion to make sharps and flats persistent

[Urs Liska]

Am 18. Mai 2020 18:48:04 MESZ schrieb David Kastrup <address@hidden>:
>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?

Exactly.
Even worse, the argument "encode what you see" makes no sense. You don't see a 
f thst is contextually an f sharp. You see a note head contextualized by a key 
and a clef. And many other conventions if you'd be consequent.

Urs

-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.