Music XML x position specs ignored on import
Create a trivial file. Add some text (ctrl/cmd T) over a note. Move it over a bit. Export to Music XML. Import it back. The horizontal positioning is forgotten. It's output to the XML file, but seemingly ignored on input. Both relative-x and default-x seem ignored.
Comments
This is indeed true in general. The basic problem is that since every program has their own concept of the default position for elements, it will almost never actually make sense to attempt to interpret manual positioning info that other programs placed into a MusicXML file.
In reply to This is indeed true in… by Marc Sabatella
!?!?! It seems to have no trouble preserving and executing vertical postioning. Why is horizontal any different? I don't understand at all. I need a way to control horizontal positioning of artifacts (via XML) and have none.
PTI, since the program that made the xml is included in the xml, then I would suggest that MuseScore honor the offsets if it came from MuseScore.
In reply to PTI, since the program that… by mike320
I've written an XML-compliant application that wants some control over positioning. Of course, I can lie and say I'm MuseScore, but that defeats the purpose of a standard. I fail to understand why vertical works but not horizontal. Are the position controls in XML essentially worthless because of buggy interpreters? The standard seems pretty clear to me about what they mean. I can pad leading spaces in my strings to fool it, but I don't understand why this is not a bug.
In reply to I've written an XML… by [DELETED] 1831606
I've rarely used xml import so I hadn't noticed x or y offsets being honored. I would say that ever honoring it would be the bug. When a program says x = -.5, what does this mean? .5 inches? .5 millimeters? .5 spaces in musescore? Every program can use it's own measurement. Since the program that created the xml in the file, programmers can write code to honor this measurement based upon which program was used to create it.
In reply to I've rarely used xml import… by mike320
!?!?! Music XML is not a chaotic beer-party hack, but a highly organized and well-designed formalism and standard! All distance measurements are in tenths of a staff-space, whose interpretation in millimeters is stated in the "defaults division" (nod to COBOL). MuseScore understands and obeys this, exporting and importing, everywhere else! Please visit the music xml site!
In reply to I've written an XML… by [DELETED] 1831606
I would say again what I said before, the position controls in MusicXML are essentially worthless not because of buggy interpreters, but as mentioned, because each program has different default layout, so a manual positioning that might make sense in one program is unlikely to make much sense in another. This is to me pretty obviously going to be more true of horizontal positioning info, since so much depends on space between notes that is very application-dependent. But FWIW, I also don't see a difference in how MuseScore treats horizontal versus vertical offsets on staff text - both seem ignored. Both in 2.3.2 and current 3.0 builds. Do you have a specific file where you see the vertical offset being honored? Maybe the syntax you are using is different than what MuseScore exports?
In reply to I would say again what I… by Marc Sabatella
Easier done than said!
In reply to Easier done than said! by [DELETED] 1831606
Interesting. Looks like your files has only a default-y; the MusicXML as exported by MuseScore has both default-y and relative-y, and I guess it's the latter that is ignored, just as relative-x is.
In reply to Interesting. Looks like… by Marc Sabatella
This was written by my code (a putative MusicXML package). x is not there because I couldn't make it work. I can make it say anything at all. I gather, thus, there is no way to control x-position into MuseScore (and it's not considered a bug but a design choice)?
In reply to This was written by my code … by [DELETED] 1831606
As far as I know this is true, but I'm not the MusicXML expert. I only tell you what I generally believe and have observed to be true. Feel free to file an official feature request to the issue tracker. Given that in general it doesn't make sense, I can't see the default changing, but I could imagine an additional checkbox in the Edit / Preferences / Import.
See also https://musescore.org/en/node/278544
In reply to See also https://musescore… by Jojo-Schmitz
To add some facts to the discussion:
MuseScore exports default-x, -y and relative-x, -y provided they are large enough. This applies to text, but possible not to all score elements. Feel free to verify how all possible elements are handled :-).
For text, MuseScore imports only default-y. Feel free to submit a pull request with improvements.
FYI, most of the MusicXML import and export code was done by me and I use the following priorities to determine what I work on (highest to lowest):
1) fixing crashes
2) importing / exporting all data correctly without layout
3) importing / exporting layout
Even though the MusicXML specification is precise enough, its interpretation by various programs is quite inconsistent. Thus I concur with Marc and find MusicXML layout import/export relatively unimportant. In case someone wants to step in and enhance MuseScore, please do.
In reply to To add some facts to the… by Leon Vinken
This is not the greatest news; although I have professional programming skills, I am not eager to take on MS development and proving operability on multiple platforms. I am experimenting with code that composes music, and was considering automatic annotation of music, for which latter this news is cold water indeed. One would hope that I do not have to learn to generate .mscx files to control common (industry-wide) features of MuseScore scores, and that is one of the reasons why Music XML exists, i.e., keeping vendor-proprietary formats opaque as they should be. One would also think that MuseScore could import what it exports. So it does seem that my choices are (1) generate mscx (2) develop MuseScore code (3) work on my organ-playing instead. Sigh ...
In reply to This is not the greatest… by [DELETED] 1831606
FWIW, 2) is a MUCH better option than 1). Learning enough about MSCX format and changing your code to generate it would be a huge undertaking, and then you would need to track all future changes to the format, which is not documented in the first place. Whereas learning enough about the structure of MuseScore code is trivial, people are often able to submit their first PR within days of starting the process. Plus you'd be doing everyone a favor, as all other developers do when they "scratch their own itch" and implement whatever features they personally are most missing - which is how pretty much everything in MuseScore came to be in the first place. I highly recommend going for it!
The multiple platform business is a non-issue. The vast majority of the code is completely platform-independent. Anything that would otherwise be platform-dependent is encapsulated by the Qt libraries, but really I can't think of anything about this particular task that would even hint at having any platform dependencies in the first place.