Shift+drag doesn't move staves anymore

• Dec 9, 2018 - 02:27
Reported version
P1 - High
Ergonomical (UX)
S5 - Suggestion

Select a measure, hold down the shift key, move the mouse. You'll draw a blue box instead of moving the staff.

I don't think there's another way to adjust distance for a particular staff.


Severity S1 - Blocker S5 - Suggestion
Type Functional Ergonomical (UX)
Priority P1 - High

There is - Staff Properties / Extra distance above staff. The ability to shift+drag was removed deliberately as I understand, since inter-staff distance is now variable anyhow. But to me that's questionable; the main use case to me for shift+drag was to create extra space betwene sections of an orchestra or other large ensemble, and nothing about the automatic staff spacing changes this. So I'll leave this open as a suggestion to add back at some point.

In reply to by Marc Sabatella

"... the main use case to me for shift+drag was to create extra space between sections of an orchestra or other large ensemble", I confirm!
so useful and indispensable feature for big conductors layout! Please restore it... I can't consider using musescore 3 without this feature!
Thanks in advance

Workaround No Yes

There is a work around. You can change the value of "Extra distance above staff" which is what ctrl+drag did automatically. The workaround does not void the fact that the function should be restored.

Just want to comment that, in working on an orchestral score, this is a significant enough frustration that I'm moving back to version 2 for the time being.

Can you explain how using "extra distance" Staff Properties to set the this doesn't work just as well? It's normally something you'd do only once when setting up the score, not something you should be constantly needing to adjust, especially with automatic placement meaning that you no longer need to add space staff by staff just to avoid collisions.

In reply to by Marc Sabatella

Hi Marc -- thanks so much for your reply.

So, where I got frustrated was in working on an orchestra score. I had a high violin note with a trill (with a flat symbol attached to the trill) at one point, and the trill line was colliding with the staff above the violin. I just wanted a little more space on that system to avoid the collision. "Extra distance above staff" seems to adjust it score-wide, which isn't really what I wanted.

More generally, I often feel the need to tweak staff spacing manually -- not just to avoid collisions, but also to keep the music from looking cramped. I like the new automatic adjustment feature, but there needs to be an easy manual override.

Actually, I just noticed the possibility of adding spacers. That seems to be what I'm looking for, but it's an awkward work-flow for something I feel I need quite often. What if shift-drag added/adjusted a spacer?

In reply to by MarcEvanstein

Shift+drag in 2.x was the exact same thing as extra distance - it too was score-wide. To add space for a single system only, spacers have always been and continue to be the way. But it's almost never needed any more in 3.0 because autoplace avoids most ollisions automatically. If you have some specific case where it isn't, please file a separate bug report on that with a sample score.

But there is literally no sense in which 2.3.2 has any advantage in this respect, whIch is why I was confused by your statement. if you want to avoid collisions, you always need spacers in 2.3.2, you very rarely do in 3.0, and Shift+drag has nothing to do with this. It was only for adding space score wide, to separate winds from brass etc, and "Extra distance" does precisely the same.thing.

Hi Marc -- thanks again for your reply. You're right -- I definitely overlooked the fact that Shift-dragging was affecting the whole score! In light of that, I agree with you that there isn't really an advantage to 2.3.2.

I may have revealed myself in this respect as a migrating Sibelius user. In Sibelius, shift-drag adjusts spacing on a particular system only, and control-drag does so while re-adjusting the other systems to compensate. I thought shift-drag in MuseScore 2 was having the same effect, but I guess it wasn't.

So I stand corrected: it's clear that version 3 is an improvement, and that spacers are what I needed. I still feel, though, that the best approach would be to have shift-drag create / modify a spacer. That would make the experience much better for users like me who often find the need to manually adjust spacing, and I can't see what the disadvantage would be. Is there one?

Well, one would be, it's not what long-time MuseScore would be expecting, but that's not a deal-breaker. It's worth a discussion in the feature request forum. I could imagine shift+drag automatically adding a spacer, but then the spacer would have properties in the Inspector that controlled whether it acted for the current system only or for all systems, also whether it should be treated as "at least this much space" or "exactly this much space" (what we currently called "fixed" spacer - when you want less space than you would otherwise get). for that matter, maybe also to override the staff distance for all staves on the current system. To me, it could also be related to things like being able to specify that empty staves should be hidden on some systems only, or to force a certain number of measures to fit.

But this particular issue is about something else, just reinstating Shift+drag as an alias for "Extra distance above staff", which is possible to in my opinion less useful since it is a relatively uncommon operation.

One more, in this comment ( which is disturbed by the disappearance of this function in version 3 (on a personal note, it was one of the most used functions in version 2 so much it was intuitive and fast, contrary to the current workaround - and I still miss it, and don't understand why this subject doesn't progress)

Can the people who used used it much in MuseScore 2 explain what their use case was? A sample score with an explanation of what they used this function for? I suspect most people probably would prefer the behavior proposed above where it actually just affects the current system, as that seems the more common use case. But maybe a solution needs to be designed that accommodates both usages.

I know people also used it in MuseScore 2 as a workaround for the lack of autoplace but that obviously no longer applies. So I’m mostly interested in the use cases that were not just to avoid collisions.

This isn't a strong or good enough reason to re-implement, but I thought it was cool. For doing a score-wide customization gap between certain instrument groups for instance, it's nice to do it quickly based on "eyes-only."

In reply to by Marc Sabatella

That would be pretty decent.
Your mentioning of adding a score-wide or system-wide quality to spacers sounds really appropriate. The thing with that is there would require a certain flexibility: score-wide would seem to require there to be multiple spacers each "linked" together that could be dynamic enough so that layout/systems could change without having a problem. And if the user "ticked" off one of them to be system wide, would it change them all to be system wide or only that one?