MusescoreXML documentation for Slurs

• Sep 8, 2020 - 13:54

I'm trying to understand the MusescoreXML format and the underlying way how slurs are conceptually encoded.

I've created a very simply case of a slur that makes an s-curve.

Slur with an S-Curve

The corresponding encoding is

<Spanner type="Slur">
    <Slur>
         <SlurSegment no="0">
            <o2 x="3.77827" y="0.485428"/>
            <o3 x="-4.10585" y="24.6961"/>
            <o4 x="-1.0377" y="0.878901"/>
            <offset x="-0.636204" y="5.82274"/>
         </SlurSegment>
    </Slur>
 </Spanner>

Is there some documentation how the slur segment is being encoded and interpreted? As far as I understand, a slur is a bezier curve with a starting point, an end point and some intermediate points (editable in MuseScore are two). Ideally this is stored in relative sizes to allow for dynamic scaling. Any information on how this is being done would be helpful.

As a bonus question: is there some information on how the solution relates to how other formats encode this? I found https://usermanuals.musicxml.com/MusicXML/Content/EL-MusicXML-slur.htm, but the documentation does not reveal how the fields bezier-x, bezier-y etc. are supposed to being handled or what information they store. MuseScore seems to ignore them when importing a score from a MusicXML file, where I manually added some values. In MEI it seems to be a list of coordinate pairs in absolute coordinates (https://music-encoding.org/guidelines/v3/elements/slur.html) inside of the bezier element.

Thank you!

Attachment Size
Screenshot 2020-09-08 at 13.30.58.png 33.42 KB
WeirdSlur.mscx 4.74 KB

Comments

• Sep 8, 2020 - 20:31

Hello! Yhere is no format called MuseScoreXML, and it's not clear from this if you are asking about the open standard MusicXML format, or MuseScore own undocumented MSCX format. I'm kind of guessing you mean the latter since that is what your example seems to show. The format is undocumented in part because we don't want people relying on details of it that might change. Generally speaking, if you're going to be working with MuseScore internal representation, we'd rather see you do it from within MuseScore itself, or by exporting to MusicXML, not by trying to reverse engineer the MSCX file format. Can you explain more about what you are actually trying to accomplish?

Reply

• Sep 9, 2020 - 13:47

Hi Marc,

I wasn't sure how to refer to the format. At least Daniel Ray called it MuseScoreXml when we discussed it, so I went with it. And yes, I'm talking about the undocumented mscx format.

My motivation is that I am working on Optical Music Recognition (https://arxiv.org/abs/1908.03608) and I'm currently tackling the reconstruction of slurs and how to represent these reconstructions. When I'm segmenting images into different classes, it is quite clear how to store most objects, simply by storing their bounding box and class name. However, when reconstructing slurs, the bounding box is unsuitable, because it contains lots of other objects. Therefore, we ideally we would recognize the underlying curve by fitting a parametric curve and storing that curve.

Here is an example of a score and the segmented curves that I am trying to reconstruct:
2.jpg 2_predict_mask_rotated.slur_.png

To understand the way how to store slurs, I investigated the way how MuseScore handles them and how MusicXML and MEI are supposedly storing this information. Since I didn't want to re-invent the wheel, I was hoping to find some information on how to best encode slurs and make the reconstruction compatible with existing formats while still allowing for useful features such as dynamic scaling. One thing that would help a lot, is if I could store the reconstruction in a manually encoded mscx file to be able to display the recognition result in MuseScore, allowing me to verify whether the optical music recognition was doing the right thing or not.

All the best
Alex

Reply

• Sep 12, 2020 - 18:19

What still isn't clear to me is if you are talking about implementing OMR within MuseScore, or if you are building an independent tool. But in neither case should the details of the MSCX format concern you. If you are implementing it within MuseScore, you want to build the data structure directly, not build the tags. And if you are building an independent tool, the output format should be MusicXML. So I'm afraid I'm still not understanding the context for this.

Reply

• Sep 12, 2020 - 22:58

The OMR tool is independent of MuseScore, but in order to get the most out of it, I wanted to understand which information I have to reconstruct. And as I said before: I don't want to re-invent the wheel but learn from mature formats how to properly encode that information. MuseScore seemed like the best place to start from.
I guess, I will have to crawl through the source-code (https://github.com/musescore/MuseScore/blob/c9f8a138529c15bf9d096e53a4a…), since you already mentioned, that there is no documentation.

Regarding MusicXML, things are not as easy as one might think. MusicXML has some information about slurs with special curvature, but MuseScore neither exports nor imports that information. If you take the example from the top, almost all information about the slur gets lost and all you have left is a standard slur. This makes is so hard to understand and verify, whether I am doing a reasonable job with slurs or not.

Reply

Do you still have an unanswered question? Please log in first to post your question.