#1659 MusicXML direction placement value ignored when imported
If this is a bug, it would probably be low priority. It's in v18-12, and I suspect in the later versions too.
RG supports MusicXML 2.0. I want to display some text above the staff lines, and this should be possible using the test-in.xml provided. Here is a snippet:
<direction placement="above">
<direction-type>
<dynamics>
<other-dynamics>1-ABOVE</other-dynamics>
</dynamics>
</direction-type>
</direction>
However, as seen in rg-musicxml-in,jpg, the text all appear below the staff line. Does RG have that direction attribute implemented yet? To test that I exported the same track back into test-out.xml and got:
<direction placement="below">
<direction-type>
<dynamics>
<other-dynamics>
1-ABOVE
</other-dynamics>
</dynamics>
</direction-type>
</direction>
So...RG does know. However when imported, it either ignored the 'above' value or overrode it with 'below' and then displayed it that way. Later, it exported with the same value. Is that a bug?
Ages ago, I did try a workaround when I noticed that RG displays the Chord text above staff lines. All I would need was the attribute it used. So, I added some chord text and exported. There was no reference to that text at all. I could not tell whether that was just not implemented yet, implemented but a bug or perhaps the chord text is just internal display and never gets output to MusicXML 2.0 as anything. Might as well get an answer to that too.
On the input side,
MusicXMLXMLHandler::startDirectionData()appears to be the place where we process this. Nowhere in MusicXMLXMLHandler.cpp is there mention of "placement". So it looks like this might be a missing feature.On the output side,
MusicXmlExportHelperappears to write out 'placement="above"' in certain situations. E.g. for tempo events.Just a quick skim of the code, so I'm not sure what's going on.... But I get the feeling that Rosegarden assigns more meaning to things than MusicXML. E.g. Rosegarden has a tempo event, while MusicXML has arbitrary text above the staff. If this is true, it will be interesting for Rosegarden to fully convert MusicXML to Rosegarden internal format. E.g. we would need to detect an "Allegro" above the staff and convert that into a tempo event. For now, one has to do this manually after importing a MusicXML file.
Anyway, just some initial thoughts to get the ball rolling if someone decides to tackle this.
Diff:
My thoughts are that I am not sure an internal RG representation is the way to go. I only say that because MusicXML is a standard, so the element names etc of v2.0 are set in stone. W3C community can't change the past to affect your code, What they've done already is created v3.0...and in fact they are now at v4.0 according Wikipedia:
https://en.wikipedia.org/wiki/MusicXML
Chances are that they have used generic names to make processing easier and perhaps you are seeing specific internal names in RG code. Not sure you have the cycles to chase after the versions :-) But RG says it supports v2.0, which is fine. I just don't know how much of v2.0 is currently supported as something users see on the music staff. I just stumbled on one case.
I'm not sure how you are with XSD, but here is the MusicXML v2.0 XSD with all possible elements (including <xs:attributegroup name="placement">), so you can compare the code names with that:</xs:attributegroup>
https://www.w3.org/2021/06/musicxml40/version-history/20/
Matching those to what's named in the code parsing the import might help.
That link also shows the other version XSDs and I noticed that the word "tempo" doesn't show up in any of them, which is little odd for a "MusicXML" :-). You'll also note they rarely deprecate and mostly add elements. So, if your parsers don't choke because an element is gone, the code can ignore new ones and will always work.
Normally, I import MusicXML v3.0 to RG and I just happened to notice the placement above/below problem. I then switched to importing v2.0 for testing in the unlikely case that the version was causing the issue...and the bug still occurred. So I reported it.
RG uses XML for its own configuration, so I'm sure you have no problems with XML. I guess you could still go the way a an internal RG XML with its own element names and use a stylesheet to translate then to v2.0. But then you have those future versions to think about. In any case, I still feel its low priority compared to main path RG bugs.
I did some more digging on this. rg supports the following text styles using the text tool (F8):
The positions for each style are fixed. E.g. we do not support the "dynamic" text style appearing above the staff. We would first need to add that feature. Then we would need to support interpreting MusicXML's version of that (placement="above"). So this is really a new feature.
As it is now, the only option would be to use one of the text styles that put the text above the staff (direction, local direction, tempo, local tempo, chord). I'm not sure whether MusicXML offers similar styles, or which of them are translated to which rg text styles. I can do some further digging if you are still interested. However, using the (e.g.) "chord" style to get a dynamic marking above the staff seems like a bad idea in the long run.
I recommend that we close this and open a feature request "Add MusicXML direction placement support".
Originally, I tried using "direction" in the text tool as an alternative since that text appears above the staff when added in RG. However the following problem occurred:
6. Now import the same MusicXML into RG and the text does not appear at all, neither above nor below the staff.
Since RG exported the direction tags, I assume they are correctly placed. But it does not import them again i.e. it's not just a placement problem...or should this be considered a different bug?
I would have considered using any of the text styles to get text above the staff, just as a workaround. But alas, I've not seen RG import any of its own text styles which should appear above the staff.
If this bug is to be renamed a new feature, perhaps it should be worded to not focus on just placement. RG needs to both import and export the MusicXML text styles it already knows about and displays on the staff, and secondary to that get their placement correct.
So it sounds like we've got two things going on here:
I was going to mention this in one of the MusicXML bugs, but since I"m not familiar with RG regression tests I let it go. In some distant past, when I've had to deal with import/exports like this, I tie the round-trip into the test itself using test XMLs (which can just be strings in the code of course) e.g.
During (1) any unsupported tags/attributes disappear, but it ensures that RG will cope with that. In (2) whatever RG exports, it really should be able to import, so by (4) the two exported XMLs should be identical.
If formatted by the same function, a direct file (or string) comparison verifies nothing went wrong. One factor to bear in mind is the order of XML attributes are in general not important in XMLs. If you get around that you can get immediate test feedback that nothing is missed or broken using simple diffs...and you can have fixed XMLs which can be updated with new tags/attributes to keep with the test as they are developed .
It's just a thought.