Urs Liska <[email protected]> writes: > Am Montag, den 18.05.2020, 18:11 +0200 schrieb David Kastrup: >> Gianmaria Lari <[email protected]> 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
