Fermatas: In imported 2.x files, the fermata in voice 2 is reset to voice 1

• May 23, 2019 - 21:37
Reported version
3.0
Priority
P2 - Medium
Type
Functional
Frequency
Once
Severity
S3 - Major
Reproducibility
Always
Status
fixed
Regression
Yes
Workaround
No
Project

OS: Windows 10 (10.0), Arch.: x86_64, MuseScore version (64-bit): 3.1.0.7024, revision: 63ba901 (and 3.1 beta)

Open the attached 2.x score and take the reset. Compare the arrangement of fermatas in 3.x to the same in 2.x.
MS 2.x:
fermata_ms2.png
MS 3.x:
fermata_ms3.png
The fermata formerly in voice 2, and below the chord, has been reset to voice 1, above the chord.

Attachment Size
fermata_issue.mscz 4.33 KB

Comments

Regression Yes No

Same in 3.0.5, so we're not currently counting that as a regression.

Fermatas changed from being treated as articulations and thus attached to chords to being treated as segment elements like staff text. In theory this shouldn't prevent us from assigning the voice and thus getting the direction right, but we don't. We should probably move the code doing this check fro readArticulation u to readChordRestProperties so we can access the chordrest track info.

Regression No Yes
Reported version 3.x-dev 3.0

Well, it is a regression, vs MuseScore 2. Just none that needs immediate action to be included in 3.1

I thought I fixed this with my patch for #273302: Fermata loses assignment to voice and direction, but it is not working now with that test file either. I wonder what changed. The value returned by e.track() when called from readArticulation() is no longer what I would expect. Changing a bit of code in Element::readProperties() from this:

      else if (tag == "track")
            setTrack(e.readInt() + e.trackOffset());

to this:

      else if (tag == "track") {
            e.setTrack(e.readInt());
            setTrack(e.track());    // this is already adjusted by e.trackOffset()
            }

solves this issue, but I do not know what other consequences that might have.