On Mon, May 18, 2020 at 11:17 AM Urs Liska <li...@openlilylib.org> wrote: [...] > 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,
In MEI, true, but actually messier: @accid Captures a written accidental. @accid.ges Records the performed pitch inflection. So, to create valid MIDI output from a MEI document, an F-sharp which appears with no sharp because there's a sharp in the key signature would need to be encoded with @accid.ges. (Rather annoying if you are creating MEI files programmatically.) > 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). > > But having "f" behave depending on what has been encoded before is > begging for disaster. Copy&paste has already been mentioned, but I > think it is already harder to *read* in the input file. This by far > outweighs the saved keystrokes IMHO. > > My 2cts > Urs > > Best, David Nalesnik