Crash when creating parts if hairpin in Voice 2

• Apr 21, 2019 - 21:56
Reported version
3.0
Priority
P0 - Critical
Type
Functional
Frequency
Few
Severity
S2 - Critical
Reproducibility
Always
Status
active
Regression
Yes
Workaround
No
Project

version 3.1 beta / Windows 10 (and current nigthly ec75e63)

Weird problem by working on something else.

Steps:

1) New score for two instruments, eg first piano staff and soprano (the test file: hairpin shortcut v2.mscz )
2) Enter four quarter notes in the first measure top staff in Voice2 necessarily
3) Select the second quarter note, and add a hairpin (no crash on the first beat), and necessarily with the shortcut "<".
(by selecting it, you notice this hairpin is highligthed in voice2, whereas if you enter it via the Lines palette, it is in voice1, even by selecting the second quarter note in voice2)
4) Create parts (new all -> Ok)

Result: crash


Comments

Regression No Yes
Priority P0 - Critical

The crash itself is a regression, this scenario doesn't seem to crash MuseScore on version 3.0.5.

However the behavior was not correct either:

  • Creating parts in a score with multiple instruments and a hairpin in the second voice leads to this hairpin appearing in a wrong part (3.0.5);
  • Creating parts in a score with a single staff and a hairpin in the second voice makes this hairpin just not appear in the generated part (both 3.0.5 and 3.1-beta).

So it looks like the crash itself is not the only issue here.

The crash occurred on last March 4.
No crash with this nightly: 00ed31b
But crash with this one: ea8da9e
There are several commits in between, but perhaps the closest commit would be the following, regarding the dynamics? https://github.com/musescore/MuseScore/pull/4541

BTW, I try to locate the problem (first part/root cause?) of the crescendo in Voice 2 that gets lost on another staff (or completely lost in part in the case of a single staff).
For the time being, I see that this issue was already present at the very beginning of 2019.

More precise observation: in November 2018.
The problem is due to the combination of voices and the crescendo.
As long as the crescendo is displayed in voice1 via the shortcut (while all notes are in voice2), then it appears in the created part. Otherwise, if it displays in voice 2 (green), then it is lost.
It remains to be seen when this change took place.
(EDIT: 15-25 november)

So, located on November 19
As explained, the change follows the "voice color" of the added crescendo:

With this nightly, 75818b6, the crescendo entered on note voice2 is displayed in voice1 (blue).

Is it an expected result, done intentionally? Or already an issue ? (eg, in 2.3.2, crescendo shortcut voice 2 displays crescendo in same voice 2, and displayed too in part)
758.jpg
Anyhow, in master: correct result in part (crescendo is shown)

To fix: #278121: Slurs are lost in parts

Indeed, the previous commit doesn't seem to be related? https://github.com/musescore/MuseScore/commit/40d4fc55c18dbd4abac086cf6…