MusicXML - staff height, spacing, and system "inset" directives not followed
Working with MuseScore 3.5.2/Windows 7
I am relatively newly working with MuseScore, so there may be some "philosophy" that fully explains (or perhaps "excuses") the behavior I report here.
Even with Preferences>Import:MusicXML:Import Layout ON, the directives in an incoming MusicXML file for the height of staves, the spacing between staves, and the "inset" of the left end of a system (from the left page margin) have no effect on the layout of the score reconstructed by MuseScore from the MusicXML file.
This can result in a substantial discrepancy between a score reconstructed by MuseScore from a MusicXML file and the original score as constructed in another application.
Again, I may just be missing some important concept here.
Best regards,
Doug
Comments
I can't answer the specifics, just the general "important concept", and that is this: historically, we've never made any significant attempt to preserve anything about the original appearance of an imported score. Virtually everything about our import has been based on getting the content correct. The idea being that it's unlikely you'll ever get all that close anyhow because so much differs from one notation program to the next in terms of basic default layout algorithms.
Only relatively recently have we've started to gradually to pay more attention to layout info, but it's still only partially there, and to some extent should probably never be expected to be perfect.
That said, I can't think of any particular reason we couldn't at least try to get some basic global defaults right if there is a straightforward mapping from the MusicXML to our own style settings. So if there is a specific MusicXML tag you feel should be mapped to a specific style setting but isn't, feel free to enter it into the issue tracker as a Suggestion. Normally we say separate issues for separate suggestions, but if it's really a group of related age layout tags that each maps neatly to a style setting, they could probably safely be combined. Any cases where there is no straightforward mapping should probably be a separate issue because it would be likely that would need to be solved separately.
In reply to I can't answer the specifics… by Marc Sabatella
Hi, Marc,
Yes, I understand. This has always been the duality-dilemma of MusicXML - it is intended to "represent a score", but is that the score as it appears, or the score as to the notation it carries (and as well, the score as it can be machine-played).
And it is beyond me to try and "steer" the development of the program through those 1-1/2 sets of objectives!
Thanks.
Doug
Hi Doug,
part of the answer is simply insufficient time to perfect the implementation (most of the MusicXML work is done by me in my spare time next to a full-time job). On top of that, MusicXML tends to provide precise low-level positioning info that either conflicts with automatic layout or is not easily translated to the corresponding higher level MuseScore style settings.
Leon.
In reply to Hi Doug, part of the answer… by Leon Vinken
Hi, Leon,
I well understand the how gigantic is even what seems like a very small area of a notation program like MuseScore, and the many paradoxes you and the other developers face in reconciling conflicting considerations. I am very grateful for all the work that brings us this wonderful tool.
Still, "my work" in this area is to try to help the developers recognize considerations that might beneficially inform their ongoing work. I am so pleased that , as busy as you all are, you take the time to enter into collegial discussions of these often knotty paradoxes.
Doug