Unknown units for x/y/sx/sy in spos/mpos files

• Oct 19, 2020 - 16:16
Reported version
3.5
Type
Functional
Frequency
Once
Severity
S5 - Suggestion
Reproducibility
Always
Status
active
Regression
No
Workaround
Yes
Project
MuseScore

Steps to reproduce:

  1. Export mpos/spos files with musescore export job

The units for x/y/sx/sy don't make sense and can't be figured out. They're the result of "pixel_distance * ndpi", which doesn't makes sense from infographist/printer point of view.

From Marc Sabatella discussing another issue related to the same functionality:
"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."
source: https://musescore.org/en/node/307253

The problem had been discussed there: https://musescore.org/en/node/311914

Proposition to fix it (already developed)
Introduce mposx/sposx file format for export job that don't apply that ndpi factor to the pixel distance, that solution would avoid any breaking change for current systems using the mpos/spos file format and allow others users to exploit those files coordinates if needed.

mpos/spos files attached had ".xml" appended to be able to attach them to the issue as well as their new fixed equivalent.

Attachment Size
repeats.mpos_.xml 2.27 KB
repeats.mposx_.xml 2.26 KB
repeats.mscz 6.19 KB
repeats.spos_.xml 8.34 KB
repeats.sposx_.xml 8.15 KB
repeats-1.png 86.17 KB
repeats.json_.txt 234 bytes

Comments

• Oct 19, 2020 - 16:23
Title Unknown units for spos/mpos positions ⇒ Unknown units for x/y/sx/sy in spos/mpos files
Frequency Many ⇒ Once
Severity S4 - Minor ⇒ S5 - Suggestion

Reply

• Oct 21, 2020 - 02:08
Status PR created ⇒ active

Another approach could be writing a plugin which would export the necessary information in any format. Plugins already have access to information on elements positions and bounding boxes. Two things seem to be missing though to cover all the functionality needed to reproduce spos/mpos-like files from plugins:
1. nextMeasureMM and prevMeasureMM need to be re-enabled in Measure object to make it possible for plugin to find out all the measure that are actually visible to a user. The corresponding properties in Score object are already available.
2. For <events> section, repeat list access would probably be needed (see also #30111: Access to Scoreview and Repeats list with plugins).

Of course, adding a better documented sposx/mposx format would also be a good thing, but adding a possibility to do this with plugins would potentially offer a larger flexibility for possible applications.

Reply

• Oct 21, 2020 - 10:19

Well, not 100% sure about parts, but check (my) batch convert plugin (which doesn't do mpos/spos currently, but might get extended for that, guess I'll add this real soon now)

Reply

• Oct 25, 2020 - 05:26

We have a way that is sufficient for users, which is just ① broken (see node #307253) and ② awkward to use. Changing the x/y/sx/sy values to directly correspond to the PNG pixels fixes the latter.

You can use plugins during batch converting with -j but that would be so much more awkward… having it as additional way might be good, but let’s fix the built-in, faster, way first ☺

Reply

• Nov 2, 2020 - 17:53
Status PR created ⇒ active
Workaround No ⇒ Yes

We have approaches at that, but without also getting https://musescore.org/en/node/312022 fixed this makes few sense, and the workaround is to divide the values from the old-format file by 12, for now.

Contrary to what I was told, the values are not multiplied by some dpi-dependent factor, only by a constant factor of 12.

Reply

• Nov 2, 2020 - 18:22

Lol dude... that's really more and more getting on my nerve, not only you commit code you didn't even try to compile nor test but you can't try to understand that line before incorrecting people ? check how ndpi is computed, it's a factor that account for dpi export settings regarding internal dpi settings multiplied by 12. If you want to con other people, at least, put effort in it. Not even willing to put the effort to prove you wrong, check SavePosition and how ndpi is computed... (basicaly EXPORT_DPI / DPI, resulting in a factor allowing to scale the internal position to the export file) damn... If you don't trust what have been told, just leave the 12 factor, remove the other computing and change your DPI settings... [but as you don't compile nor test your commits, might doubt will ever be possible]. (cause indeed, default value will give ((360/360)*12) change your 360 png export setting to something else, and repeat the previous sentence.. argh ) If you followed the issue deeply, you would have understand most of my incompréhension was the fact of using DPI, which makes no sense outside of a print context, that is in fact kinda of PPI named DPI, but had to dig to realize that. damn.

Also, should perhap's have update this, that's right, not even willing to put any more effort in this.
As on github, you just try to look smart with low effort and too much self confidence, that's really hard to handle, as the fix to divide by 12 to have the actual pixel value was told by me from the start barely, even had to specifically tell you that on github as you continued to think values doesn't makes sense as is...

Reply

• Nov 2, 2020 - 18:50

Please do read what I wrote, not what you think I might have written. (Or ignore it altogether, the previous comment of mine was a status update for anyone else watching.)

My starting point were the values in the existing files, having a mystery factor. Then on https://musescore.com/groups/improving-musescore-com/discuss/5078314 first BSG was rather unhelpful in figuring it out, then you came in and told me it was a constant factor scaled by DPI.

Turns out that this initial comment of yours was untrue, or at least formulated in a way that threw me off until I found out only YESTERDAY that the scaling factor between PNG and mpos/spos is only a constant 12 and the dpi are NOT multiplied in twice.

Yes, the dpi occur in the code, but that’s just to scale the internal values to the PNG; this scaling is implicit.

And no, I did not follow this issue deeply, I was interested a bit but do not have enough time to invest into that.

Anyway, we have a workaround now, and I’ll revisit this when I have more time.

Reply

• Nov 2, 2020 - 19:00

Indeed, that's on of the main difference between a cocky attitude and mine, variables names have meaning, musescore is a cathedral, and I was, at best, really cautious before asserting something being wrong (had long discussion on this forum and others to understand both DPI/PPI concept and whjat was done), if a variable is named ndpi, it's not without meaning nor intention behind, and it took me time to check and assert all the swapping and the real meaning behind, also the factor 12 fix was given to you on .com when another user notified you when I digged into the code, about 3 weeks ago (16 oct), barely on day 1, also was repeated on irc as well as github about a a week ago... It was never an issue barely from day one after getting into the code to use the files, nor for you. Also, at all points, I've given code snippet etc, you stayed silent... Also changed drastically my solution based on github discussion you answered longly too, did you read ? It was discussed there too...

And I read: "Contrary to what I was told, the values are not multiplied by some dpi-dependent factor, only by a constant factor of 12." is wrong. It's dpi dependant, not only a factor 12.

You make it all look like it was obvious, but you were looking about this since june dude... june... if it was that easy both to understand and check, why did you had to ask that many question ? really easy to attack the one who digged once the answers are barely all given.

Reply

• Nov 2, 2020 - 19:08

“the factor 12 fix was given to you on .com” → no, it was not. It was insinuated it was 12 multiplied with a preferences-dependent value.

What you take for “cockiness” is, in reality, frustration that you continue to be insulted by my attempts to explain what happened, where we misunderstood each other, and to defuse.

Can we, please, just understand that this is all based on multiple misunderstandings caused by trying to communicate with a French native speaker in English, which is nowhere near the native language of either of us?

Thanks.

End of meta discussion.

Reply

• Nov 2, 2020 - 19:20

Nope it's not, what I take for cockiness is commiting untested not even compiled code, having so much trust in yourself that you consider first that others are wrong or will be your servant, QA-ing your code, what I consider cockiness is someone clairly having bad practice but trying by all means to justify it nor put effort in understanding others. It's really funny on how people who reviewed the code put online really good remarks I totally accounted for, but yet, not here... at some point, as for the code, can't always get the problem source on myself. I kinda understand now why people at BSD projects rejected your work and "you didn't liked them". Just the way you phrase it is symptomatic of why it end like that. But hey, have fun, gg, hope Koen will one day have his fix, to not deceive him, I took my responsibility to tell him someone else is on the issue and I'll have no more time to dedicate on this nor this project. The codebase really reflect the actual interaction, no surprise in the end.

Reply

• Nov 2, 2020 - 19:35

It’s a pity you apparently never exchanged ideas in “here’s a rough draft, do you think this could work?” form with a coworker when working on something together, and that you have to attack ad hominem now, but meh. I have wasted too much time on this already, I need to get some billable hours in.

Status update for the general public I asked Koen whether he can share publicly what he shared with you (since you apparently don’t want to do this), so someone else wanting to pick this up can do that. I saved the latest WIP as https://github.com/mirabilos/MuseScore/tree/fix-mpos-spos for reference. I don’t have time for this (I had hoped that I could include a backport of this in the next Debian upload quickly, but, alas, it shan’t be for now) but might come back when I have more time. I direly need to get quite an amount of billable hours in now, to fulfill my contractory obligations with $dayjob, and stop working until late in the night on hobby projects ☹

Reply

• Nov 2, 2020 - 19:48

I asked Koen whether he can share publicly what he shared with you (since you apparently don’t want to do this), so someone else wanting to pick this up can do that.

WTF... really, I shared everything new he added, I'm not retaining any information, he mostly provided me test files of working and non working ones or validate some changes, similar to the ones he already uploaded at the end, and asked him few question about the previous behaviour, mainly confirming what was already supposed and written everywhere in the related threads... damn... I mention him indirectly a lot on github and mentioned him a lot (legacy client, current consumer/user, etc) with you on IRC... I even asked him about the changes you wanted to make on the file format to know what his opinion was and so could represent/mention him when discussing the changes... but I'll always be wrong anyway, as you only think you could only right. I'll just have to accept it and let go, that's just pissing me off so much as it depict a so wrong picture of this, damn... even here, shouldn't, answer, I know it, but damn, people like you that's just crazy, how can you be so off with reality of what happened considering there's conversation logs both on the forum and github since I started to write code for this... can't understand...

Reply