Hairpins malpositioned, causes crash upon repositioning

• Dec 14, 2018 - 23:16
Reported version
S2 - Critical
needs info

When you select a note, then select a hairpin from the Master Palette, a hairpin appears above the staff. Single click and hold in order to move it around shows that the hairpin belongs to the staff where your note is at. Double clicking it reveals that it belongs to the staff above. Trying to reposition the hairpin causes the staves to re-space themselves as you see in the diagrams, and on one occasion, a crash.

OS: Windows 10 (10.0), Arch.: x86_64, MuseScore version (64-bit):, revision: 59a11cd

Attachment Size
hairpin1.png 10.48 KB
hairpin2.png 10.97 KB


Status active needs info
Type Graphical (UI) Functional

The staff repositioing is normal. MuseScore now automatically adds sufficient space for symbols between the staves. Since you (like it or not) have a hairpin attached to the top staff, when you drag it down, MuseScore dutifully adds space to keep it from colliding with the staff below.

That much then is by design, and the fact that it is attached to the top staff is a known issue. The crash is new, but in order to investiate, we could need steps to reproduce. I'm leaving this open because of the crash but setting the status to needs info, because we need to knoew how to reproduce the crash.

In reply to by [DELETED] 29378932

In the first example, I have one instrument. When I input a note and choose a crescendo hairpin, it draws the hairpin below the note, as it should be.
But if I add a second instrument, input a note, and draw a decrescendo, instead of adding the hairpin to the not of the second instrument, it adds it to the first, disregarding the fact that I wanted the hairpin to go on the second staff.
In this case, the hairpins overlap. Is that by design? I think not. The workaround? Disable the godforsaken "automatic placement" for the hairpin in the Inspector. But why go through the extra trouble that did not exist in version 2.3.2?
As for the crash, it happened only once, and I haven't been able to reproduce it. Since it happened in the act of tying to shake that hairpin off of my cursor I'm pretty sure it'll happen again.

Attachment Size
2-1.png 41.43 KB
1-1.png 23.04 KB

In reply to by mike320

No. Situation is unchanged. The :D was for make happy face.
Steps to Reproduce:
1. New > Choose Instruments template > add two violins, any key, any number of measures
2. On the lower staff, enter a note (Upon entering note, it is selected automatically)
3. shift-F9 for the Master Palette
4. Choose Lines > crescendo or decrescendo hairpin, it doesn't matter
5. The hairpin you chose appears above the staff. In previous versions, this would appear right below the note.
6. Double click the hairpin. You will see that for some reason it belongs to the upper staff. Upper staff contains no notes.
7. Click on the hairpin to select it, and then open Inspector.
8. Disable "Automatic Positioning".
9. You will see that even though the hairpin can move now, it still belongs to the upper staff.
Previous versions of Musescore don't do this behavior. For now the workaround remains disabling Automatic Positioning, and then hoping for the best, or revert back to version 2.3.2.
Thanks guys for all your help. I can see there remains a few things to iron out. I will download again when it's not a beta. :D (happy face for make smile, not to say "OMG I make error") Thanks.

To be clear: the problem with the hairpin being added to the wrong staff is already known. As mentioned previously, that much is a duplicate of #278490: Lines placed above the top staff when single note selected.. The issue only occurs when clicking a single note and then double-clicking the palette icon; the other methods of adding hairpins (select region then double-click palette icon, or use keyboard shortcut, or use drag and drop) all work fine. So using one of those other methods is the true workaround. Disabling autoplace might enable you to drag the hairpin where you want it, but this won't really work, as it will still be attached to the wrong staff and thus will not link to parts correctly, will not look correct if the layout changes, etc.

So thanks for the steps you list above, but that much we already did know. The "needs info" in this issue report is about how to reproduce the crash. And yes, there are things to iron out, which is why this is a beta, and we appreciate the help we get from users like you reporting bugs!