hairpins split between systems lose manual formatting after system break
If you add a multi-measure hairpin to a vocal staff and move it above the staff,* and then the score is reformatted so that the hairpin is split between systems, the portion of the hairpin after the system break ends up back in the default below-the-staff location. This seems like a bug to me, but a quick scan of the issues list didn't turn up a match to this symptom.
OS: Windows 10 (10.0), Arch.: x86_64, MuseScore version (64-bit): 3.0.0.4785, revision: c1a5e4c
- where it belongs, and where IMHO it should be possible to have it placed by default, but that's another topic
Comments
For the record, it's possible to place hairpins and other elements above the staff by default via Format / Style, but indeed not possible to have different defaults per staff. That's a long-standing request that hopefully will get implemented some day.
Meanwhile, if you're not using the style to set the default, then I'd say not necessarily a bug that manual positioning doesn't apply to both segments of a hairpin if it later gets split across systems. Sure, it makes sense in this particular context where you were moving all hairpins above, but it doesn't apply to all such manual adjustments, which might be just to avoid collisions. So we support the ability to do these manual adjustments for each segment individually.
In reply to For the record, it's… by Marc Sabatella
I'd love to see statistics on how many hairpins are moved above the staff to avoid collisions with lyrics vs. how many are moved to avoid collisions with anything else. I'd bet that the former are in the majority. I still think the default ought to be to move the whole hairpin together if the user has specified a non-default position. For one thing, if the hairpin was moved to avoid a collision with something other than lyrics, how do you know that the collision happened in a measure that precedes the system break? If the collision occurred after the break, current behavior would do exactly the wrong thing, and restore a collision that the user has explicitly tried to avoid. Second, if I'm a musician playing or singing from a score and I see a hairpin above the staff, I'm going to look in the same place after the system break to see if the hairpin continues. I think it's fairly counterintuitive to have what is conceptually a continuous hairpin switch from above the staff to below it, even if a system break intervenes. Third, changing the default so that the hairpin stays where the user placed it would do nothing to affect "the ability to do these manual adjustments for each segment individually." It would simply remove the necessity of doing these adjustments for each segment individually.
In reply to I'd love to see statistics… by ghicks
The problem arises when you want to just move one part of the hairpin to avoid something but not above the staff. You need to be able to move the parts independently. I would say that if you select a section of notes that include both parts of the hairpin and then you select all hairpins in the selection (right click select>all similar items in selection) then both parts should move. I didn't test to see if this is the case or not.
In reply to The problem arises when you… by mike320
That's not at all the use case I had in mind. In my case, I create a multi-measure hairpin and move the whole thing as a unit from its default position to above the staff. Later edits cause the measures to be reformatted so that there is now a system break in the middle of the hairpin, and at this point the part of the hairpin that is after the break reverts to the original below-the-staff position. It's my contention that it should not do this. This actually seems to happen to me a lot lately and I find it bothersome. I feel like "I already told you this hairpin should be above the staff, and now you've decided to move part of it back where I said I didn't want it."
You say "you need to be able to move the parts independently" as if I'm proposing that this be prevented somehow. I'm not. I'm merely asking for an existing hairpin (or part thereof) not to be automatically repositioned as a result of a system break. If, after the system break is inserted, the user wants to move part or all of the hairpin, this should still be possible, and I don't see how what I'm asking for would change that.
In reply to That's not at all the use… by ghicks
I can't argue with you about that one specific use case - moving a hairpin above the staff for a lyric staff. Clearly, what you suggest works there. The problem is that is not the only use case for manual adjustments to lines, and indeed it's doubtful it even accounts for a majority of them. What about, say, a volta that currently extends across two systems and you've adjusted the horizontal offset of the start point on the second system to align with something, but then the layout changes and now it's only one system? Does it make sense to keep the manual adjustment made on that second system now that it's only one system? Or, a trill where you make a slight vertical adjustment at the beginning to accommodate an accidental, and then later that trill ends up spanning a second system - does it make sense to apply that same adjustment to both? And about a 100,000 other cases where you either go from a single system to multiple systems or vice versa, times about a dozen types of manual adjustments.
In some of those cases. sure, whatever heuristic we use for the case of hairpins on vocal staves might sense, but in other cases, it almost certainly doesn't. There are just way too many use cases with too many different expectations for one approach to always work, unfortunately.
To me the only real solution to that particular problem of haipins on vocal staves is as I said - per-staff style settings. Then you can set hairpins to be above the vocal staff by default and don't need to rely on manual adjustments, and we don't have to worry about if whatever kludge we come up with to special case those particular manual adjustments on those particular staves make sense to also apply in other situations.