Crash when creating parts if hairpin in Voice 2

• Apr 21, 2019 - 21:56
Reported version
3.0
Priority
P1 - High
Type
Functional
Frequency
Few
Severity
S3 - Major
Reproducibility
Always
Status
closed
Regression
Yes
Workaround
No
Project
MuseScore

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

• Apr 22, 2019 - 17:17
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.

Reply

• Apr 22, 2019 - 17:54

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.

Reply

• Apr 22, 2019 - 18:19

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)

Reply

• Apr 22, 2019 - 19:03

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…

Reply

• Nov 21, 2019 - 14:41
Status active ⇒ needs info

I cannot reproduce the crash now. But this issue persists:

> 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

Can anybody confirm?

Reply

• Nov 21, 2019 - 15:32

Curiouser and curiouser. I can confirm the single stave behaviour, but I experimented a bit further with a four part score. The hairpin actually appears on the part below the one it is attached to in the part. It doesn't matter if voice 1 is empty or not. See the attached example and compare which bar the hairpin is located in the score with the location in the parts. Hairpin placement differs in score and parts.mscz.

I found it does the same with a great stave. A hairpin attached to voice 2 in the upper staff appears below the bottom staff.

Reply