Use of `u` to encode ligatures

[lpugin]

We have many incipits where + has been used for encoding ligatures instead of ties.

• For representing ligatures in mensural notation
• For representing ligatures with stem-less notes (7.)

We need to clarify if this is supported or not. If yes, tooling needs to be adjusted accordingly. We should also consider adjusting the specifications to use another sign.

(We also have cases where + has been used to represent slurs. This is simply wrong.)

[BaMikusi]

As far as we can tell, this primarily affects records entered by the German working group, and after circulating the explanatory pdf regarding the new PAE validation function, we in fact received a very emphatic request from the Dresden colleagues not to delete the + characters from these records (wherein, by the way, they mostly added a note explaining the ligature implication of these + characters). Their estimate is ca. 2.000 such records from the German working group (whereby other cataloguers might of course have done something similar, e.g. after incidentally coming across such German records and taking them as a model).

It seems to me that the + sign is not practical here (and the essentially horizontal tie in fact looks quite hideous as rendered by Verovio when connecting different pitches), but if you could imagine implementing some other solution, I shall for now give the German colleagues a neutral answer that we take a closer look etc. To my mind, ligatures (speaking of a "plaine & easie" code) kind of fall in between: they are not as irrelevant as a slur or a sfz marking, but also not as integral as a tie. Also, they are hardly essential for incipit comparison, but if Verovio supports mensural notation also in its outward features (clefs, note-heads and stems), ligatures are of course also a rather characteristic part of that.

[BaMikusi]

(Which is not to say that ligatures should actually be shown as ligatures, since users not specialized in this period could then likely not read them properly.)

[lpugin]

Verovio's support of ligatures can be seen here https://www.verovio.org/test-suite.xhtml?cat=ligature. You will see that it also has a rendering option to show them as bracket, so there is some flexibility on how to show them.

I understand and agree they should not be dropped. You can reinsure our users on that. I would still prefer for ligatures to be migrated to a specific character, especially if + is being changed for ties anyway. I would avoid l because it can be mistaken with I or | depending on the font. Maybe i?

[BaMikusi]

Ah, OK, sorry, I wasn't aware of this rich repertory of Verovio ligatures -- whereby Muscat/OPAC/rism.online should IMO simply show individual notes as grouped with brackets to make sure every user is on board.

[ahankinson]

As far as I know, the square bracket isn't yet defined in the PAE code itself (only supplied accidentals in the key signatures); perhaps this could be used for ligatures?

[ahankinson]

Or perhaps the tilde? C~D

[BaMikusi]

I wonder whether some cataloguers might also have entered obviously missing notes etc. in square brackets in the incipits themselves. (No idea, just guessing.)

[jenniferward]

I wonder whether some cataloguers might also have entered obviously missing notes etc. in square brackets in the incipits themselves. (No idea, just guessing.)

Not that I know of; for better or worse, we're usually strictly as-it-is-on-the-source, but Martina or Guido probably know more.

[lpugin]

• []: I don't think we need something that structuring (with a begin and an end). It would make migration quite more complicated. Also, I would prefer to keep it exclusively to key signatures. We would potentially introduce confusion because in key signatures, they are used to encode something not in the source, but for ligature they would have a completely different meaning. We have a similar problem with () which are used for both tuplets and fermatas. This makes parsing quite more complicated and should be avoided - see https://github.com/rism-digital/pae-code-spec/issues/3
• ~ would make sense. I thought about it, but then feared confusion with the validity note delimiter https://www.iaml.info/plaine-easie-code#toc-5.

[ahankinson]

I guess that's linked to the fate of #25.

[BaMikusi]

Just a thought regarding the automatic revision of + signs as used for ligatures: Is it plausible to assume that + signs appearing in mensural notation in fact always stand for ligatures?

Background: some members of the German working group who use + sings in this sense indicate this practice in a remark to the incipit, while others not. Furthermore, I could imagine that some other Muscat users could have come accross the German records and might have started to use + signs the same way. If so, finding a rule of thumb for the identification of such records could be useful, since in these we would need to change the + characters to some other sign (once we'll come to an agreement what that should be for ligatures), while in a great number of other records + signs between two different pitches should simply be deleted (likely reflecting slurs in the original source).

[lpugin]

Is it plausible to assume that + signs appearing in mensural notation in fact always stand for ligatures?

Probably yes, but we cannot be sure we do not have exceptions in the data. For the very reason that incipits are sometimes coded as mensural only because of the appearance of the notation in the source. Then ties are possible. Here we can check if the pitch is the same, because that would be impossible in a ligature. If they coded slurs, then it would become quite difficult for us to detect. There should not be many, though. Maybe looking at the duration could give us a clue.

[lpugin]

I just came across this example https://rism.online/sources/553004244/

Tie or ligature? That is the question...

[BaMikusi]

If the pitches are identical, it shouldn't be a ligature, so I am happy to amend my hypothesis thus:

Is it plausible to assume that + signs appearing in mensural notation between notes of different pitches in fact always stand for ligatures?

[jenniferward]

Just heard from Julie Cumming's group which has also been encoding with a + with a remark that includes the word "ligature." Example: https://muscat.rism.info/admin/sources/1001160119 (1.4.1)

[ahankinson]

Just a note: This is starting to cause issues in RISM Online.

In the incipit search, we use Verovio to extract the pitches and intervals from PAE so we can search for this. In order to avoid 'double-matching' on tied notes, Verovio ignores the second note of every tie, on the theory that the interval does not change.

However, for notes that are encoded as ligatures with +, this means we are starting to see some false positives in the searches: A search for, say, "EDCDEEE" will find incipits of "EDCDEDEDE", where the two "ED" intervals are encoded as ligatures. This is matched because Verovio does not count the "ED" interval, because they are "tied".

As for what to replace it with, I think we have either the tilde (~) or the underscore (_). From #1 , we can see that the underscore has some historical precedence for ties, but I think that ship has sailed. I think of the two, I might prefer _ for ligatures, with the idea to reserve the tilde for slurs, if and when we support them.

(For no other reason than slurs are round, and ligature brackets can be square, so the visual appearance of these characters is a small hint.)

(I should say, also that the issue with matching isn't that these are not close matches -- it's that the search system thinks they are exact matches, and can rank them higher than actual exact matches)

[BaMikusi]

I should add that + is not simply used for ligatures in many records, but also for slurs -- which is of course even more wrong (in that it has, to my knowledge, never been sanctioned by the ZR even informally), and is quite frequent nonetheless.

[ahankinson]

Is anyone opposed to the use of a beam group {} to indicate ligatures for neume and mensural notation? I think it's preferable over the use of ties since it is a grouping mechanism rather than a mechanism that has rhythmic effect.

[lpugin]

Yes, I think this would be a bad idea. I would suggest instead a single letter but different from ties _. l is probably not a great idea, but maybe u? We had ~ discussed before.

[ahankinson]

I think it's a good idea! :-D

A beam is a kind of ligature, and it also uses a grouping character (of which we have only a few to choose from). I also like the fact that the start and the end are different, otherwise it's harder to detect incorrectly nested groups. And they don't blend in with the other letters. (of which there are many).

{AB{CD} makes it easy to detect the error because you can tell at the second opening bracket that it's a problem, while uABuCDu is only detectable when you don't have a fourth u, and it's all the way to the end before you know that. uABuCDyy would be better if we went that way.

You could also compare something like:

{AB}{CD}{EFG} to uAByuCDyuEFGy. I think the former looks much better, and is probably easier to type.

Except for a few sources in transitional periods, beams and ligatures are generally mutually exclusive in the different repertoires. This idea occurred to me as I work through the neume notation encoding draft, where it's likely going to be very common to have lots of grouped notes, so I think some sort of enclosing characters are preferable.

[lpugin]

Except for a few sources in transitional periods, beams and ligatures are generally mutually exclusive

This is why the idea is not as great as it looks like ;-)

Since we are trying to disambiguate PAEC, it seems like adopting the beam code for ligatures is going in the wrong direction. I understand there is a similar concept of bracketing, but still, we are talking about something very different and applyied to different duration values. This will cause a lot of additional checks and potential confusion.

Also, since the tie code has been used for ligature, I don't think we need to change to a container code { and } with something that should remain a side feature. Staying with a flag-like code is enough in my opinion.

[lpugin]

PS Maybe I was not clear. I am simply suggesting to replace + with u. So 7C1D+E7F would become 7C1DuE7F

[ahankinson]

I've changed the title to indicate the current direction of travel on this issue.

[BaMikusi]

Footnote for the Verovio rendering: while I agree that it's meaningful to treat neumes and ligatures together as regerds encoding, the rendering of neumes should IMO better be done by grouping, i.e., the noteheads belonging to the same neume should stand closer together. Using braces over the staff is not out of the question, but while that's a well-known practice for ligatures in modern editions, in plainchant studies it is (to the best of my knowledge) the grouping solution that has established itself as an informal standard.