Ties Being Erroneously Added to Ligatures

[DanielS146]

In Music Input, there is a bug when inputting a ligature: ties are inexplicably being added to the notes (see below).

[karend27]

@lpugin @craigsapp Do you have any idea why this might be happening? (it's a new behaviour).

[craigsapp]

This is related to conversion from Humdrum into MEI. Previously I suppressed "hanging" ties, but now I show them, and display them in red if they do not hang off of the start or end of the music (as part of a musical example). I would need the Humdrum data to see why it is happening (either there are actual ties added to the ligature notes, or something strange is happening).

If you can tell me the key sequence and URL on the interface to go do, I can probably look under the hood at the Humdrum data before it converts into MEI data.

[karend27]

Hi @craigsapp:

If you go to https://measuringpolyphony.github.io/mp_editor Then Click "Use Sample Document" button Then Click "Continue to Music Editor" Then enter a folio number so that you can pretend select to start entering music (say enter 1r) Then hold the shift key, drag to select a staff so that it creates a dashed box, click it so the box is solid Then type the following key sequence (this should enter a two-note breve-long ligatures, with a rest after the first one): c[0e9d]r[0e9d][0e9d] But instead you get:

I noticed if you try to enter two ligatures in a row it just breaks, but with a rest in between as above you can do it.

[craigsapp]

@JRegimbal: How can I see the Humdrum data from the javascript console?

In the prototype interface https://menput.humdrum.org:

There is a variable called MUSICLIST that I can ask for the Humdrum score:

MUSICLIST.getHumdrumScore();

But in mp_editor, that object is not accessible, or is renamed, or is made into a local variable not available from the console.

I think that I know the problem (mixing of mensural music ligature marks with modern music tie marks), so I should otherwise be able to fix the problem this weekend.

---

Another possibility (or temporary fix) is to use an older version of verovio. I added "hanging ties" to the Humdrum-to-MEI converter last month: https://github.com/humdrum-tools/verovio-humdrum-viewer/issues/196 which is causing the problem (it now outputs red ties when they are not attached to the same note on both ends). Ties are encoded in Humdrum with [ and ], so they are getting confused with the ligature symbols.

Here is a version of verovio from 11 July 2020 that should be hanging-tie free:

https://raw.githubusercontent.com/humdrum-tools/verovio-script/d362b/scripts/verovio-toolkit-wasm.js

If that works, then that might be better as it will avoid surprises in the future :-).

[craigsapp]

Fixed! (https://github.com/humdrum-tools/verovio-humdrum-viewer/issues/369)

Now ligatures should not have red ties attached to them:

[craigsapp]

Or for you 😺 :

[karend27]

thanks @craigsapp !! @JRegimbal have these fixes been moved over to our development site or to the main github site? I'm not seeing the ties anymore on the development site, but there are still unexpected behaviors happening when I try to enter ligatures.

[JRegimbal]

Both right now should be puling Craig's changes, but it's possible there is still an issue with how I'm handling ligature inputs. I'll have to take a closer look at it.

[karend27]

So here's an example of funky things happening. The ligature is supposed to start on the thirteenth note in this passage - a two semibreve ligature starting on the note e. I typed the keys [1ed] but you can see it joined up with the previous note which was supposed to be a single minim on the note f and created a strange ligature shape that does not exist.

When you move to score editor the note values are correct but there are no ligatures at all.

[I've attached the MEI file I downloaded at music input stage and the console file] Archive 2.zip

[craigsapp]

It would be useful if the interface were able to download the Humdrum data before it is converted into MEI file. In that way I can determine if it is a problem in the raw key input conversion into Humdrum, or the Humdrum into MEI conversion, or something happening after converted into MEI (in which case it becomes @lpugin's fault :-).

This would also allow the interface useful for Humdrum users to use for data entry from manuscripts. c.f., A Diplomatic Edition of Il lauro secco: Ground Truth for OMR of White Mensural Notation Emilia Parada-Cabaliero et al., ISMIR 2019, Delft, The Netherlands.

[karend27]

@JRegimbal do you think this is possible - to add a button that allowed the Humdrum data to be downloaded at the music input stage?

[JRegimbal]

Added it. It should be reflected on the GitHub pages site in a few minutes.

[martha-thomae]

I have a few questions here:

1. Shouldn't it be 1e[ followed by 1d] instead? I am asking because that seems to work. I don't remember the original way we chose for encoding these.

So here's an example of funky things happening. The ligature is supposed to start on the thirteenth note in this passage - a two semibreve ligature starting on the note e. I typed the keys [1ed] but you can see it joined up with the previous note which was supposed to be a single minim on the note f and created a strange ligature shape that does not exist.

2. Yes, this is because we are encoding them as <bracketSpan> elements, which are actually an element from CMN and they are supposed to go within a <measure>. So, technically, it isn't valid MEI. And Verovio is not handling them (probably it does when it is used within a <measure>? no idea).

When you move to score editor the note values are correct but there are no ligatures at all.

[I've attached the MEI file I downloaded at music input stage and the console file] Archive 2.zip

[craigsapp]

Thanks! Can you put a link to the editor on the page: https://github.com/MeasuringPolyphony/mp_editor then I would not have to search for the web address in my email.

You would click on the gear icon to the right of the "About" text on the right side of the page to add the link (I can't do it since I do not have admin access to the repository):

Then I would not have to search my email for its address :-)

---

Alternatively, it could be set up to be:

https://editor.measuringpolyphony.org

which I would be able to remember after a while. I could work with @karend27 to set that up (probably with video conference as I watch you enter the data in your domain name register's website). There would be two steps:

(1) Add a file called CNAME in the repository that has the contents editor.measureingpolyphony.org, although there is a location on the Github Page settings now for such a thing (maybe it creates the CNAME file). (2) Go to the Domain Name Registrar, and create a CNAME record pointing to your GitHub repository. Here is the one I created for https://menput.humdrum.org on GoDaddy:

The name of the website is menput.humdrum.org (so that is the menput field), and it points to craigsapp.github.io which is the GitHub account on which the menput repository is located.

---

Or alternatively, you could think of a new domain name to use for the editor, such as www.mensural-editor.org...

[karend27]

@craigsapp thanks for the idea about changing the URL - that's a much easier one to remember. If you could walk me through it that would be helpful - I'll send you an email.

[karend27]

I have a few questions here:

1. Shouldn't it be 1e[ followed by 1d] instead? I am asking because that seems to work. I don't remember the original way we chose for encoding these.

So it used to be you didn't have to re-enter the number if it stayed the same (whether typing ligatures or single pitches). So you only entered the number when the rhythmic duration was different. So for that string of minims for instance you just enter 2ggfef

[karend27]

It seems like the open square bracket is not being captured. At the beginning of entering a system I typed c for the clef, used up down arrows to get it in place and tried typing [0gfg] for a three-breve ligature (and @martha-thomae it didn't seem to matter whether I typed [0g0f0g] or [0gfg] it still didn't work). When I typed the final close bracket ] a pop-up error alert says "No open ligature to close!" I'm attaching the humdrum file and the console measuringpolyphony.github.io-1599158460574.log

b45cbce2-241f-4287-91fa-8b75350c0d87.txt

[martha-thomae]

I have a few questions here:

1. Shouldn't it be 1e[ followed by 1d] instead? I am asking because that seems to work. I don't remember the original way we chose for encoding these.

So it used to be you didn't have to re-enter the number if it stayed the same (whether typing ligatures or single pitches). So you only entered the number when the rhythmic duration was different. So for that string of minims for instance you just enter 2ggfef

Sorry, I wasn't very clear. When I said:

Shouldn't it be 1e[ followed by 1d] instead

I was questioning the position of the initial bracket, not the missing duration for the second note. I meant that the bracket always follows the note (so, 1e[d] rather than [1ed]). I think I tried it with the bracket (initial or final) following the note and it was working.

[craigsapp]

It would be good to post the Humdrum data for the ligature problem. Either the conversion from keypressed to Humdrum is having problem (which I suspect the most), or there is a problem converting the ligatures from Humdrum into MEI. I or you can verify if it is related to the Humdrum-to-MEI conversion by copy-and-pasting the Humdrum data into Verovio Humdrum Viewer. If the Humdrum data looks good but the notation has the problem, then the problem is most likely in the Humdrum-to-MEI conversion; otherwise, if there is something quirky in the Humdrum data (such as a missing ligature mark or the mark is on the wrong note), then the problem is most likely in the conversion of the keypress list into Humdrum data.

[karend27]

Ah okay - you're absolutely right @martha-thomae - my mistake. So the ligature entry does seem to be fine now. I am going to go back over some of the other bugs listed that document issues with ligatures and check these. Then I'll come back and close this issue if everything looks good. Thanks!

[karend27]

Okay - I am going to close this now. Two ligature bugs remain open with new comments from me.