Saving segment positions with MuseScore 3 leads to elements with sx attributes being mostly 0

• Jun 27, 2020 - 19:07

(I wasn't sure if I should post this here, on in the more general user support forum, but felt like this would probably be the most fitting sub-forum given it's low level / development nature. But feel free to move it somewhere else)

Hi,

I use MuseScore in command line mode to export .mpos and .spos files with measure and segment positions.
For the .mpos files, both MuseScore 2 and 3 do their work correctly (with a small change in positions, but that's probably not a bug, more a small difference in the rendering).

But for the .spos files, MuseScore 3 outputs elements that have mostly an sx="0" attribute. In fact, I think the only elements that don't have an sx of 0 are rests (but not entirely sure about that).
So there is now no way any longer to know the correct bounding box of the segments.
--> I believe this is a bug, isn't it? Can this be fixed somehow?

I did my tests with MuseScore 2.3.2 and MuseScore 3.4.2.9788, on Windows 10 64-bit latest updates.
These are the commands I used:

"C:\Program Files (x86)\MuseScore 2\bin\MuseScore.exe" -o test-ms2.spos test.mscz
"C:\Program Files (x86)\MuseScore 3\bin\MuseScore3.exe" -o test-ms3.spos test.mscz
"C:\Program Files (x86)\MuseScore 2\bin\MuseScore.exe" -o test-ms2.mpos test.mscz
"C:\Program Files (x86)\MuseScore 3\bin\MuseScore3.exe" -o test-ms3.mpos test.mscz

If you look at the test-ms3.spos file, you'll see that sx is 0 for most elements...

I'm attaching the test file + the obtained result files for your convenience and for reproduction purposes
(note that I had to post-fix the names of the .spos and .mpos files with .txt because the forum won't allow me to upload these types of files).

Attachment Size
test.mscz 42.18 KB
test-ms2.spos_.txt 74.7 KB
test-ms3.spos_.txt 71.76 KB

Comments

Frankly, I had no idea such options were supported, and am not surprised at all they don't work - pretty much never do we pay attention to that code when making changes. If you explain you are relying on this for, maybe we can help you find a better way.

In reply to by Marc Sabatella

Hi Marc,

with that functionality, we can generate .png images from a MuseScore file + have a corresponding mapping of wall-clock time to position (note or measure rectangle) on the image. We need this for a (still beta version of) our score follower. You might remember Thomas and Nicolas doing demo's with this technology connected to MuseScore several years ago.

We actually also have C++ code to import scores from a user's MuseScore account (after authorizing with OAuth), but apparently the MuseScore API is now no longer working, so this now also no longer works in our application. It was convenient for a user to import his/her own scores that way, but I can understand that decision...

So, the code was changed to start MuseScore locally in a separate process to perform the conversion and generate the .png, .wav, and .mpos/.spos files locally on the user's own computer from a local MuseScore file. And then I noticed the .mpos file is still OK in MS3, but the .spos file has these widths of 0 (which was not the case in MS2). It looks like the bounding box calculations for notes doesn't work any longer as it used to and leads to zero rectangle widths for the elements (except for rests, I think)?

I had a quick look at the code in MuseScore, and noticed some things are done while iterating over the score elements, but it wasn't clear to me what was going on exactly and why this would now fail in MS3...

Hopefully there is a simple fix?
In any case, thanks for your fast reply.

Kind regards,
Koen

In reply to by KoenTanghe

I do remember that project, very cool! Well, like I said, to my knowledge, no one has maintained the part of code responsible for writing these tags, and much has changed about the layout algorithms, so it doesn't surprise me things don't work anymore. Probably best to have someone on your team figure out what is needed and implement it themselves, we can try to help but you know your requirements between than we do.

In reply to by Marc Sabatella

Sorry for the late reply.

The requirements are simple, really: element tags should have a non-zero widths (sx attributes) when .spos files are generated (just as it was done correctly in MuseScore 2, and as it still is done correctly for the elements when an .mpos file is generated).

It's a bit daunting for an outsider to have to setup an environment that can build MuseScore from source, and then try and figure out what might have changed in the source code compared to previous releases that now leads to these zero widths for elements.

I did check out the repository and had a look which code actually generates these .mpos and .spos files, and from what I could see. it's the methods saveMeasureEvents and savePositions defined in the source file mscore/savePositions.cpp that does this, so probably something changed in there (or in the underlying way element bounding boxes are calculated). These methods get called from doConvert in mscore/musescore.cpp.

So, I think for now, I'll submit a bug report in the issue tracker with this information, and hope one of the current developers can find a brief moment to look at the existing code and knows what might have changed compared to MuseScore 2 (and why it still works for measure elements, but not for note elements).

In reply to by KoenTanghe

Understood that going in directly might be time consuming, but realize also, most of the rest of us have literally no idea what those numbers were supposed to be. Like how they were supposed to calculated, what the units are, etc. So even just a really good precise description of what the numbers are supposed to represent would help.

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