Curious statement in the MEI Guidelines

[ahankinson]

@gregchapman-dev made an observation on Slack about a statement in the Guidelines that seems curious:

"Because these attributes may not be required in all situations (such as @dur for the notes of a chord), processing software should anticipate retrieving the information that would have been provided by missing attributes from a preceding <note> or <chord> parent in the same <layer>. Only information from @pname, @oct and @dur attributes can be gathered in this fashion. No other attributes can be treated this way."

This would seem confusing, since it would imply that a note with no duration can take its duration from a preceding note on the same layer which is ... weird.

I do understand that a note that is within a chord can / should take its duration from the <chord> duration.

Doing a bit of digging, this particular statement has been carried through from the MEI 3.0 guidelines. Can anyone clarify what this means? Can / should this be clarified in any way?

[rettinghaus]

This is totally weird, because it (partially) contradicts the definition of @dur.default.
https://music-encoding.org/guidelines/dev/attribute-classes/att.duration.default.html
Or consider the melodic line c - b - c. A human would consider this to be a half tone down and up again, how should a software know that the b should have a different @oct value than the note before? (A software could do that, but it's not clear from the description.)

I would consider the statement simply wrong and would remove it completely.

[bwbohl]

I do remember stumbling over this at some point in my involvement with MEI and filed it in the "strange but accepted due to tradition" category ;-)
It seems feasibly plausible when you consider encoding by hand (maybe even without any intellisense). As an encoder, you only would have to enter these attributes when a change occurs. So the example by @rettinghaus could, e.g. read:

<note pname="c" oct="4" dur="4" />
<note pname="b" oct="3" />
<note pname="c" oct="4" />

Good for fast encoding and also good for illustrative purposes to show where substantial changes occur. But yes, I agree that it seems somewhat out of tune with contemporary encoding philosophies. Would love to hear @ axelberndt on this and if and how he deals with this in https://github.com/cemfi/meico!

[ahankinson]

@bwbohl I think, though, that this definition would conflict with notes that truly don't have a duration, as is the case in some chant repertoires where the duration is unspecified, or in certain treatise examples where they simply want to illustrate pitch with no implied duration. In these cases the same software (or indeed a different human) could not determine whether a note has no duration, or a note should take its duration from a previous note.

[bwbohl]

Yes, absolutely, and in combination with @dur.default, there would at least be the need for some encodingDesc for human readability and with our general tendency towards machine-readability some possibility for encoding a precedence or @dur="unspecified" or the like…

[DILewis]

It's not impossible that this was done with some tablature ideas in mind. Tab chords do in practice inherit duration from previous chords, but the current recommendation is to have @dur anyway, and add <tabDurSym/> when there's a rhythm sign. I can't remember how previous versions work.

[craigsapp]

"Because these attributes may not be required in all situations (such as @Dur for the notes of a chord), processing software should anticipate retrieving the information that would have been provided by missing attributes from a preceding <note> or <chord> parent in the same <layer>. Only information from @pname, @oct and @Dur attributes can be gathered in this fashion. No other attributes can be treated this way."

This is very bad and should be forbidden: there should be no implicit milestone transference of parameters amongst sibling elements. The problem is that "preceding note" in the general sense cannot be completely defined (consider piano music where voices come in and drop out), so it is very problemmatic to find a previous note in the previous measure. What happens if the previous note is inside of a reading, etc.? Also allowing this introduces recursion and/or forces temporal processing of the data.

Deriving the duration from the parent <chord> is not a problem since that is a hierarchical situation rather than milestone. There will always be a single unambiguous <chord> nearest ancestor element for the note, even if it were embedded in a secondary structure such as a reading. Of course@pname and @oct make no sense since every note in a chord has a different pitch, but it is useful for @dur (as well as @dots, @dur.ges, @dots.ges, etc.).

If the duration/pitch/octave information needs to be extracted from a "previous" element, then some formal mechanism should be used such as @corresp to indicate which previous element the attributes should be inferred from.

[craigsapp]

Or consider the melodic line c - b - c. A human would consider this to be a half tone down and up again, how should a software know that the b should have a different @oct value than the note before? (A software could do that, but it's not clear from the description.)

As a side note: the SCORE notation editor allows two modes for inferring the octave for a note. There is "octave" mode which keeps the same octave number as the previous note, and "proximity" mode which moves to the closest note within a fourth from the previous note, where the octave may change (as in your example).

"octave" mode is the default:

"C4 b c" → C4 B4 C4

"p" is used to start proximity mode:

"C4 pb c" → C4 B3 C4

"o" is used to (re)start octave mode:

"C4 pb c ob c" → C4 B3 C4 B4 C4

[ahankinson]

I’d say the difference here is in note entry vs note storage. It’s fine as an input optimization to do this, but there’s really no reason why an encoding format should do it. I’ll bet that SCORE doesn’t actually save the file this way.

[craigsapp]

Yes, for SCORE it is only for note entry. Afterwards the pitch data is converted into to what would be note@loc in MEI (but in certain cases you can reverse the process to edit the input form of the data again).

The Guido Music Notation uses the system of inferring the duration and octave from the previous note: https://en.wikipedia.org/wiki/GUIDO_music_notation (I haven't tried this with @pname type data, but accidentals are definitely not allowed to behave in a similar manner and are only local to one note). And Lilypond behaves about the same way as GMN (Lilypond even allows pitch to be expressed differently for different languages).

[lpugin]

Plaine and Easie does infer duration and octave from the previous note(s). (The pitch is needed since it encodes the note itself.)

'4CEG''2C

[craigsapp]

For entertainment, here is a webpage and Google slides for a collection of digital music representations encoding the same melodic fragment, much of the underlying differences between the formats are about this sort of thing:

https://docs.google.com/presentation/d/1S5f4zoV1heXEAwtYY4knpg7HfhykDXxNu6q6auAA4a4/edit#slide=id.g4d4fce5b8c_2_75

https://wiki.ccarh.org/wiki/Rosetta_Stone_of_Musical_Data_Codes

(Slides 24 and 25 show the difference between SCORE input and SCORE data & PAE is on slide 6)

[ahankinson]

I especially like the Finale and Sibelius encodings.