Attached file still triggers this issue with the current 3.x. It contains one of the parts found in the original mscz file in https://musescore.org/en/node/326798, but with most of the notes removed.
And the fix for that it to have the keysig (3 sharps) at the first measure, not at the first after all mm-rests, then also the exported musicxml is clean!
For the file attached to https://musescore.org/en/node/341863, the root cause seems to be that function wordsMetronome() in file exportxml.cpp fails to parse the tempo's text. It seems related to the use of multi-measure rests, but I still don't understand all details. More debugging required.
I suspect the exporter assumes the TextBase passed into wordsMetronome() always has a valid layout, but this is not true for the TempoText in the failing cases (TextBase.isLayoutInvalid() returns true).
Seems that it goes wrong in TextBase::fragementList() which returns an empty list !?!
We never get into the inner for loop here:
std::list<TextFragment> TextBase::fragmentList()const{
std::list<TextFragment> res;for(const TextBlock& block : _layout){for(const TextFragment& f : block.fragments()){/* TODO TBD
if (f.text.empty()) // skip empty fragments, not to
continue; // insert extra HTML formatting
*/
res.push_back(f);if(block.eol()){// simply append a newline
res.back().text+=u"\n";}}}return res;}
And the apparent trigger for all this mess seems to lay in the missing key sig at the start of the sample score (no keygsig, not just C-Major/a-minor, just none at all). But why???
It may not be related to multi measure rests at all?
But even with an initial keysig the export still looses the <fontsize="10"/><fontface="Edwin"/><b>Andantino quasi Andante</b> tempo text
And import does strange things to the rehearsal marks A, B and C (but not D): it places them below the top staff rather than above. Probably an entirely differtent issue though
Attaching two simple test files, created by MuseScore 3.6.2, containing three empty measures and a tempo text. The multimeasure version still results in the MusicXML exporter finding an invalid layout in the TempoText (which probably explains the empty fragment list). This is with MuseScore 4, commit b443bf7 of June 1, running on Linux.
Same thing, trigger is the apparently missing initial key signature.
Take Tempo_measure_rest_362.mscz, disable mm rests, add a C-Major keysig to the first measure, enable mm rests, export to MusicXML -> no problem
Hmm, strange, it isn't quite that, the saved closed and reopened score has the same issue, but when doing this in one session it works, guess it does cause a re-layout?
And the invalid tempo text isn't the only issue, there's at least one other issue with empty direction-types, with (multi) measure numbers, not with your small sample score though, but with that Agnus Dei
It seems TextBase::fragmentList() (last updated by commit 10ebbb9 on Aug 1, 2018) is missing a fix introduced in the similar function TextBase::plainText() (added by commit 3653f4b on Nov 19, 2018). The fix relayouts a clone of the TextBase when it encounters a TextBase with an invalid layout. With this fix the "Agnus Dei" export seems OK to me. Issue is present in both 3.x and master. I think this would be the structural solution. Can provide a PR for master later.
As an improvement, I suggest TextBase::fragmentList() should be moved to be next to TextBase::plainText() in textbase.cpp, the stress the similarity.
Yes, that is correct. Note that I will still be cleaning up my branch (removing unnecessary LOG statements) and adding a testcase, I am not completely done yet.
_Fix #293441: [MusicXML export] invalid XML export: direction-type is missing child element
TextBase::fragmentList() (last updated by commit 10ebbb9 on Aug 1, 2018) is missing a fix
introduced in the similar function TextBase::plainText() (added by commit 3653f4b on Nov 19, 2018).
The fix relayouts a clone of the TextBase when it encounters a TextBase with an invalid layout._
Comments
Came up again in https://musescore.org/en/node/312225
Relates to #270643: [EPIC] MusicXML import/export issues
Sorry for multiple reporting.
I should have searched on "direction-type" to see that the problem was already reported.
Could not get reproduced in current master (e3ec24f of 2021-07-30)
Attached file still triggers this issue with the current 3.x. It contains one of the parts found in the original mscz file in https://musescore.org/en/node/326798, but with most of the notes removed.
Isn't it then a duplicate of #326798: [MusicXML] Ties in cue notes?
The issue does not occur in the current master though.
It does happen in 4.0.0 too
With the XML from https://musescore.org/en/node/341231
Came up again in https://musescore.org/de/node/341863#comment-1191886 (along with mscz and mxl)
Has the issue with 3.6.2, 4.0.2 and the latest development builds
See https://www.w3.org/2021/06/musicxml40/musicxml-reference/elements/direc…
Content
Exactly one of the following
...
But here they are empty:
Here apparently lacking
<words>...</words>
?, but in other places it is justInterestingly with the score from that report Mu4 crashes when exporting it to MusicXML with Multimeasure rests disabled
And the fix for that it to have the keysig (3 sharps) at the first measure, not at the first after all mm-rests, then also the exported musicxml is clean!
For the file attached to https://musescore.org/en/node/341863, the root cause seems to be that function wordsMetronome() in file exportxml.cpp fails to parse the tempo's text. It seems related to the use of multi-measure rests, but I still don't understand all details. More debugging required.
Yeah, I looked into that that method too and couldn't figure out where and why it goes wrong
I suspect the exporter assumes the TextBase passed into wordsMetronome() always has a valid layout, but this is not true for the TempoText in the failing cases (TextBase.isLayoutInvalid() returns true).
There's two places where
setLayoutInvalid();
is called, one in the context of multi-measure rests, in mmrestrange.cpp:The other in measurenumberbase.cpp:
And except for the initialisation the only other place where it is set to true is in textbase.cpp:
Seems that it goes wrong in
TextBase::fragementList()
which returns an empty list !?!We never get into the inner for loop here:
And the apparent trigger for all this mess seems to lay in the missing key sig at the start of the sample score (no keygsig, not just C-Major/a-minor, just none at all). But why???
It may not be related to multi measure rests at all?
The initial issues seems fixed though in current master, only the score from https://musescore.org/en/node/341863 still fails
But even with an initial keysig the export still looses the
<font size="10"/><font face="Edwin"/><b>Andantino quasi Andante</b>
tempo textAnd import does strange things to the rehearsal marks A, B and C (but not D): it places them below the top staff rather than above. Probably an entirely differtent issue though
Attaching two simple test files, created by MuseScore 3.6.2, containing three empty measures and a tempo text. The multimeasure version still results in the MusicXML exporter finding an invalid layout in the TempoText (which probably explains the empty fragment list). This is with MuseScore 4, commit b443bf7 of June 1, running on Linux.
Same thing, trigger is the apparently missing initial key signature.
Take Tempo_measure_rest_362.mscz, disable mm rests, add a C-Major keysig to the first measure, enable mm rests, export to MusicXML -> no problem
Hmm, strange, it isn't quite that, the saved closed and reopened score has the same issue, but when doing this in one session it works, guess it does cause a re-layout?
And the invalid tempo text isn't the only issue, there's at least one other issue with empty direction-types, with (multi) measure numbers, not with your small sample score though, but with that Agnus Dei
For the tempo text I have a (crude) fix:
It seems TextBase::fragmentList() (last updated by commit 10ebbb9 on Aug 1, 2018) is missing a fix introduced in the similar function TextBase::plainText() (added by commit 3653f4b on Nov 19, 2018). The fix relayouts a clone of the TextBase when it encounters a TextBase with an invalid layout. With this fix the "Agnus Dei" export seems OK to me. Issue is present in both 3.x and master. I think this would be the structural solution. Can provide a PR for master later.
As an improvement, I suggest TextBase::fragmentList() should be moved to be next to TextBase::plainText() in textbase.cpp, the stress the similarity.
Preliminary fix (plus debug output) in https://github.com/lvinken/MuseScore/tree/293441-direction-type-missing….
So the fix to
TextBase::plainText()
in 3653f4b needs to get added toTextBase::fragmentList()
?Yes, I can confirm that it does fix it. I'll backport it to 3.x, see https://github.com/Jojo-Schmitz/MuseScore/pull/124
Yes, that is correct. Note that I will still be cleaning up my branch (removing unnecessary LOG statements) and adding a testcase, I am not completely done yet.
PR https://github.com/musescore/MuseScore/pull/17848
Adjusted mine (for 3.x)
Fixed in branch master, commit a658fca1f4
_Fix #293441: [MusicXML export] invalid XML export: direction-type is missing child element
TextBase::fragmentList() (last updated by commit 10ebbb9 on Aug 1, 2018) is missing a fix
introduced in the similar function TextBase::plainText() (added by commit 3653f4b on Nov 19, 2018).
The fix relayouts a clone of the TextBase when it encounters a TextBase with an invalid layout._
Fixed in branch master, commit ab0b70d907
_Merge pull request #18056 from Jojo-Schmitz/293441-direction-type-missing-child
Fix #293441: [MusicXML export] invalid XML export: direction-type is missing child element_
Automatically closed -- issue fixed for 2 weeks with no activity.