[Musicxml Export] - End-bar items lost due to various fraction offsets

[hhpmusic]

Issue type

Import/export issue

Description with steps to reproduce

Violin_Sonata_No.3_Sonata_Epica-_Nikolai_Medtner.zip

Supporting files, videos and screenshots

In this score, at bar 40, there are 3 incorrectly exported things:

1. Trill, the fraction is 5/8, so it should be offset to next note, not ended at the same note.
2. "rit." should have a small offset from the end.
3. The last dynamic pp is missing.

What is the latest version of MuseScore Studio where this issue is present?

4.4.4

Regression

No.

Operating system

Windows

Additional context

No response

Checklist

• This report follows the guidelines for reporting bugs and issues
• I have verified that this issue has not been logged before, by searching the issue tracker for similar issues
• I have attached all requested files and information to this report
• I have attempted to identify the root problem as concisely as possible, and have used minimal reproducible examples where possible

[pacebes]

I will try to tackle it.

[pacebes]

Hi.
I need some feedback. I have been able to export the last dynamic pp for the time being.

I am now dealing with the Trill and I think there may be a limitation with musicXML export. I mean the the start and the end of a Trill are linked to a Note when it begins (wavy-line is the item) as in this example:

      <note default-x="501.67" default-y="-4">
        <pitch>
          <step>E</step>
          <alter>-1</alter>
          <octave>5</octave>
          </pitch>
        <duration>6</duration>
        <voice>1</voice>
        <type>quarter</type>
        <dot default-x="516.06" default-y="-4"/>
        <accidental>flat</accidental>
        <stem>down</stem>
        <notations>
          <ornaments>
            <trill-mark/>
            <wavy-line type="start" number="1" default-y="6.25"/>
            <accidental-mark placement="above">natural</accidental-mark>
            </ornaments>
          </notations>
        </note>

or when it ends:

    <note default-x="907.67" default-y="-16">
        <rest/>
        <duration>2</duration>
        <voice>1</voice>
        <type>eighth</type>
        <notations>
          <ornaments>
            <wavy-line type="stop" number="1" relative-x="7.06"/>
            </ornaments>
          </notations>
        </note>

I have read https://www.w3.org/2021/06/musicxml40/musicxml-reference/elements/wavy-line/ .Parent elements: barline or ornaments (which in turn depend on notations - notes). I haven't been able to find any example with trills whose parents where barlines. According to the standard ( I am an absolute beginner) https://www.w3.org/2021/06/musicxml40/musicxml-reference/elements/barline/ If a barline is other than a normal single barline, it should be represented by a element that describes it. This seems to mean that we could only include wavy-line attached to a barline if it is not a single barline.

So if you export this score:

and import the musicxml you get

As you can see the first Trill is correctly imported because it ends in a rest while the second one is incorrect because it can only end in a rest or a chord and it ends at the beginning of them.

I would appreciate any feedback about if there is a way to end a Trill in something different that a note

[hhpmusic]

When I looked into the mscx code, it seems this trill is a bit strange, not correctly ending at the note, but with a fraction value. It should be attached to the ending note, no matter what the fraction is given, because the trill mark always applies to all the notes it runs over, not half of a note. I'm not sure if I'm correct when interpreting the mscx code

Haipeng

[pacebes]

Within the .mscx Trills, like KeySigs, TimeSigs, Rests and Chords are "sons" of voices. Trills and Chords are at the same level:

        <voice>
          <KeySig>
            <eid>6SNTUiuz3lB_4/E7xtf+37O</eid>
            <concertKey>1</concertKey>
            </KeySig>
          <TimeSig>
            <eid>mMzg5B4HjrJ_6HhMhPVJqZH</eid>
            <sigN>9</sigN>
            <sigD>8</sigD>
            </TimeSig>
          <Rest>
            <eid>uXLuyThJXMH_9m1z3xhh0+B</eid>
            <durationType>eighth</durationType>
            </Rest>
....
          <Spanner type="Trill">
            <Trill>
              <subtype>trill</subtype>
              <eid>q25Uop9jrrK_BnmrmdhFvxM</eid>
              <lineWidth>0.142943</lineWidth>
              <Segment>
                <subtype>0</subtype>
                <offset x="0" y="-0.5"/>
                <off2 x="0.564812" y="0"/>
                <eid>l9WHQkPbCLN_aSTg5P6mQIK</eid>
                </Segment>
              <Ornament>
                <Accidental>
                  <subtype>accidentalNatural</subtype>
                  <eid>OyN5jb/QYwE_/roYxYB038M</eid>
                  <placement>above</placement>
                  </Accidental>
                <intervalAbove>second,major</intervalAbove>
                <subtype>ornamentTrill</subtype>
                <eid>SV/gDfclFmH_TPd9PlwLzTK</eid>
                </Ornament>
              </Trill>
            <next>
              <location>
                <fractions>5/8</fractions>
                </location>
              </next>
            </Spanner>
          <Chord>
            <eid>R+NU4vcPql_Lw2EZv8xjqL</eid>
            <dots>1</dots>
            <durationType>quarter</durationType>
            <Note>
              <eid>JK0IYCImn2_OBJCNFX71IM</eid>
              <Accidental>
                <subtype>accidentalFlat</subtype>
                <eid>WfAyKkUZu9O_VsHVa8CTOaL</eid>
                </Accidental>
              <pitch>75</pitch>
              <tpc>11</tpc>
              </Note>
            </Chord>
          <Rest>
            <eid>bf14u38AovG_TbjfpeJ9fEC</eid>
            <durationType>eighth</durationType>
            </Rest>
          <Rest>
            <eid>f6EpLB0eXNJ_LxYC8mWuWTB</eid>
            <durationType>eighth</durationType>
            </Rest>
          <location>
            <fractions>-1/16</fractions>
            <timeTick>1</timeTick>
            </location>
          <Spanner type="GradualTempoChange">
            <GradualTempoChange>

...
          <Spanner type="Trill">
            <prev>
              <location>
                <fractions>-5/8</fractions>
                </location>
              </prev>
            </Spanner>

it seems that the position of each element is next to the previous one, and when something (such as "ritardando") is within tow element you have a "location" element at the same level (as Chords, rests, Trills) that correct the location of the following element.

Anyway, I don't see any parameter/option in https://www.w3.org/2021/06/musicxml40/musicxml-reference/elements/wavy-line/ that could indicate a different offset to the note the Trill is attached to

[hhpmusic]

The best solution is to make a round-up to bounce this offset to the nearest note. This is the only and currently best solution.

[pacebes]

The best solution is to make a round-up to bounce this offset to the nearest note. This is the only and currently best solution.

I am not sure about what you are proposing;

• In some cases the author would like to end the Trill in a note or a rest. This works in current version
• If, as in your case, the author would like to end the Trill within two notes we should be able to add this information to the exported MusicXML with the tags included in the standard. I don't see any tag to add this information
• Besides, MusicXML is an Exchange Format between different software. That means that anything we could add to the MusicXML should be accepted by others with the same semantic. Otherwise exported MuseScore Scores would be wrongly imported by other programs.

[hhpmusic]

Probably I didn't read the code correctly, due to I can't see the actual score. Do you mean the trill ends between two notes instead of on the second one? The trill will only be played over notes not halfway. When you said "within", do you mean between two notes or the trill lasts through two notes? When I read this part using a screen reader, it seems the trill's end falls on the second note, which will cause Musicxml write the wavy line end on that note. I'm a bit confused, sorry.

Haipeng

[pacebes]

I will try to explain myself.

See attached file example: Score_26208_trills_test1.zip

Original MSCX

• First measure trill ends just when the Rest starts
• Second measure trill ends between the Rest and the end of the measure
• Third measure trill ends just when the quarter Rest starts
• Fourth measure trill ends between the quarter Rest and the eight Rest

If you export and import them (attached files) you get:

Every Trill ends in a Rest (or Chord) because the MusicXML standard links the start or the end of a trill to a Chord or a Rest

MuseScore does not have this limitation because it has its own way to save the information. What MuseScore seems to do (mscx file) when the Trill does not end in a Chord is:

Second Measure: after the rest (quarter with dots) it adds a negative "location" to put the trill before the rest ends

          <Rest>
            <eid>ZKJCraEwJ/J_6Z6m54BGaPJ</eid>
            <dots>1</dots>
            <durationType>quarter</durationType>
            </Rest>
          <location>
            <fractions>-1/8</fractions>
            <timeTick>1</timeTick>
            </location>
          <Spanner type="Trill">
            <prev>
              <location>
                <fractions>-5/8</fractions>
                </location>
              </prev>
            </Spanner>

Fourth Measure: after the rest (quarter) it adds a negative "location" to put the trill before the rest ends, then it adds the trill and adds a positive "location" (the same as subtracted before) , so the following rest (eight) starts in the right position

          <Rest>
            <eid>NCKbKUCtr5C_5DsOiE68EAC</eid>
            <durationType>quarter</durationType>
            </Rest>
          <location>
            <fractions>-1/16</fractions>
            <timeTick>1</timeTick>
            </location>
          <Spanner type="Trill">
            <prev>
              <location>
                <fractions>-15/16</fractions>
                </location>
              </prev>
            </Spanner>
          <location>
            <fractions>1/16</fractions>
            </location>
          <Rest>
            <eid>6FSAnskWtrJ_gZpty0hs0UP</eid>
            <durationType>eighth</durationType>
            </Rest>
          </voice>

This can't be done (at least I haven't found a way to do it) with MusicXML standard because the start and the end of a Trill are linked to a Chord/Rest.

[hhpmusic]

Thanks, now I know what it happens. For Musicxml, this is indeed a limitation. Then we have to get a temporary solution: If there's a note/rest, then a fraction for the end of a trill, when the fraction is positive to shift the trill end to between this and next note, then the export puts the wavy line end to the next note; if it's a negative value then positive to compensate the duration, thus the trill ends between this note and the previous note, then the wavy line ends at this note.

Haipeng

[pacebes]

About

"rit." should have a small offset from the end.

The problem is related to the fact that the line of the tempo change is not Visible

I don't know why, but it means the segment "parent" to the tempo change is a "Time tick" instead of a "ChordRest". I presume there could also be a corner case because if there are two "tempo changes" in the same measure (such as "accel" and "rit") and both have the line invisible the program only imports the first of them such as in: Score_26208_test3.zip

[hhpmusic]

Ah, if it's invisible, then it should be hidden. Probably I missed this parameter.

[pacebes]

Ah, if it's invisible, then it should be hidden. Probably I missed this parameter.

Just the line
Visible:

Invisible:

It is especially noticeable when you export the score to PDF:
Visible:

Invisible:

I have yet to determine how can we have two different tempo change with invisible lines in the same Measure. I presume this should be allowed. Isn't it @oktophonie ?

[pacebes]

Thanks, now I know what it happens. For Musicxml, this is indeed a limitation. Then we have to get a temporary solution: If there's a note/rest, then a fraction for the end of a trill, when the fraction is positive to shift the trill end to between this and next note, then the export puts the wavy line end to the next note; if it's a negative value then positive to compensate the duration, thus the trill ends between this note and the previous note, then the wavy line ends at this note.

Haipeng

This seems to be a bit complex. Besides it will no work when the trill ends after the last note/Chord of the measure as in this case:

[hhpmusic]

Indeed a difficult thing, and perhaps this is also an incorrect engraving.

[pacebes]

I have been trying to find out why some tempo figures are not imported correctly from musicXML and I haven't been able to know which are the rules when you have TempoLine and TempoText in the same measures.

MuseScore exports every element to the .musicxml file. The importer has some rules about when to import some elements to the Measure or not. There is a parameter to determine if they can infer the text types:

and regular expressions to guess if the element is a tempo line
"(accel|faster|mosso|rit|rubato|slower|stretto)"
or a tempo text {

u"adag", u"alleg", u"andant", u"a tempo", u"ballad", u"brisk", u"determination", u"dolce", u"expressive",
            u"fast", u"free", u"gently", u"grave", u"larg", u"lento", u"stesso tempo", u"lively", u"maestoso", u"moderat", u"mosso",
            u"prest", u"rubato", u"slow", u"straight", u"tango", u"tempo i", u"tenderly", u"triumphant", u"vivace" };

Due to the fact that I don't know which are the rules regarding tempo texts and tempo lines I don't dare to change this part of the code

I will prepare a PR to solve the problem with "The last dynamic pp is missing".

[pacebes]

I have created the PR #26388 to deal with the problem "The last dynamic pp is missing".
About the other in this issue, as far as I understand:

• Trill, the fraction is 5/8, so it should be offset to next note, not ended at the same note. It can't be done because trills (MusicXML standard) start and stop in a Chord or in a Rest
  "rit." should have a small offset from the end. The problem was related to the fact that the "rit" didn't have lines ( _ _ _ _) because the line was invisible. Therefore there are tempo text and not tempo lines.

If this is not the case, please let me know.

[hhpmusic]

That's ok, thanks! Yes, if line is not shown, text is needed.