[MEI encoding] Syllable should not have both `precedes` and `follows` attributes

[JoyfulGen]

In the latest version of rodan.staging, syllables sometimes get encoded with both a precedes and a follows attributes. This shouldn't happen.

This file contains an example, ID: m-abb9b807-fc06-4a94-8cf8-b0770b21e81d. 165v.mei.zip

It's also weird that all three syllables involved are on the same staff, which means they don't have to be toggled in the first place. I'm noticing, however, that the syllable that's toggled twice is between two custodes. Is that what's making it toggled?

@yinanazhou what should happen if a custos is in the middle of a syllable? In Einsie, a custos only appears before a staff break, but sometimes if the IC identifies stuff wrong a custos will end up in the middle of a staff in a straight-outta-OMR file. Is a toggle the correct thing to do in that case? Or should the custos be inserted into the syllable?

[yinanazhou]

I will need to check the latest version of MEI encoding job to be sure. But maybe @timothydereuse knows how the previous version handles this case?

[timothydereuse]

@JoyfulGen, can you supply the intermediate inputs to the MEI encoding job that produced that MEI file? I'm unable to replicate this issue with the folios I already have on hand.

[JoyfulGen]

@timothydereuse this should do it! I'll also give you my current mei_encoding csv file just in case.

165v PF.json 165v TA.json csv-square_notation_neume_level_newest.csv

[timothydereuse]

aha! here`s the culprit:

Because the neumes on the adjacent page are kind of squished horizontally by the angle of the page, one of them was identified as a custos by the IC, and the staff was implicitly continued over onto that fragment of the next folio. So we have a long syllable on "mi" that contains two custodes and a divline and some other neume gibberish. The MEI encoding job dutifully breaks the syllable into two parts when it sees a custos, assuming there to be a line break. So, here, seeing two custodes, it breaks one syllable into three parts.

I think it is safe to flat-out make sure that two custodes cannot appear next to each other like this, and if that actually occurs in a manuscript for some reason then that can just be fixed in Neon - does that sound reasonable? I know custodes can appear in the middle of staves (not at a line break), right?

[JoyfulGen]

@timothydereuse that makes sense! Custodes can indeed appear in the middle of staves, usually before a clef (@annamorphism please confirm!). I understand the solution, I think, but I don't completely get how limiting the number of custos per staff will work. For instance, sometimes the IC misidentifies a glyph in the middle of the staff as a custos. If that happens, will it then not be able to correctly identify the actual custos at the end of the staff, because its custos quota has been met?

Another question: why does a custos provoke a toggling of a syllable? If a divisio or an accidental are within a single syllable, mei_encoding inserts them into the syllable. Could the same be done for a custos?

[annamorphism]

@JoyfulGen I think it's safe to say that the next thing after a custos is (in real music) always either a clef, or a line break followed by a clef; they shouldn't be followed by other custodes or by notes. I think (?) what @timothydereuse is proposing is not actually a "quota" on the custos, but some sort of rule using this to get rid of offending custodes before they start wreaking havoc on how syllables are split up. I think I agree that the custos could/should just be inserted in the syllable, but I am out of my depth on this piece of the process...

[timothydereuse]

@JoyfulGen: If I recall correctly, by the standards of MEI, custodes are not allowed inside <syllable> tags, so breaking out of one when you see a custos is obligatory. I'll double-check if this is still the case in MEI 5, but I remember us having this dilemma a few years ago. Hopefully I'm wrong, that would be simpler. Edit: Confirmed, syllable is not in the list of tags that can contain custos.

And yes, I just propose to make sure that multiple custodes do not appear inside the same syllable. So, if we associate a syllable with a bunch of glyphs, and those glyphs include more than one custos, I will make sure only one of them gets included (and therefore, at final encoding, it cannot be "broken" multiple times).

Edit: on second thought, maybe it is possible on some manuscript (if unlikely) that the same syllable could legitimately be sung over three lines, if the column size is very small, and have multiple custodes. I can't imagine this happens often, but I know there exist syllables that are intended to be sung for many, many neumes in sequence. Is this a case I should bother thinking about?

[timothydereuse]

Okay, I verified with the official MEI 5.0 Schemas and the Jing RNG Validator (which is, by all accounts I can find, the most trustworthy one). A syllable tag with both <precedes> and <follows> does successfully pass validation. So, I can find no reason to make sure that it can absolutely never happen. I will, however, add something to make it less likely that two custodes appear right next to each other like this.

@yinanazhou - Does it make sense to make Neon fully compatible with having both precedes and follows in the same syllable? It might be necessary in some strange cases. But probably not many.

[JoyfulGen]

@yinanazhou I've only just noticed (sorry) that Neon is still giving an error notification when an MEI file has syllables with both precedes and follows attributes. Since this is not a mistake anymore, should the error notification be removed?

[yinanazhou]

@JoyfulGen is the change already up in Rodan? The PR mentioned above has not been merged yet.

For Neon, I would say that it's always better to double check. @fujinaga what do you think?

[fujinaga]

Think about what?

[yinanazhou]

Think about what?

Should the error notification be removed in Neon?

[fujinaga]

Yes.