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?

In reply to by Jojo-Schmitz

Do you really believe that all users who perceive this know or take the time to search the Issue Tracker?

Do you believe that all users systematically report any other problems?

On the French forum, for example, if I didn't do the reports myself, nobody does! Because they don't have the time, most often because of the language barrier, and they don't want to write in English, or simply because they hope others will do it for them!

I can think of two or three issues that I haven't report lately.
So when you say 5, or more or less, that's a minor argument for me. It's just that it's a regression from version 2, that's the point. And whatever the arguments that downplay it, a regression takes precedence.

Frequency Many means more than 5. Nothing to to with Major or Minor, which would be the severity or a bug, this here isn't any, but a Suggestion, AKA feature request. Priority is High, that should be enough.

BTW: if you want it fixed, go ahead, I'm sure your Pull Request would be very welcome. This is Open Source after all. Bitching and moaning that bug still hasn't been fixed or some feature still hasn't been (re-)implemented isn't going to help in any form or shape.

Too easy answer, ready-made, you type the ball somewhere else: you know very well that I don't know how to write code. Infortunately!

Earlier I asked, "Can the people who used it much in MuseScore 2 explain what their use case was?" I got no replies to this, and we're still thinking about ways shift+drag might be used, so it would still be good to understand better.

What I'm hearing now - for the very first time in this context - is that one use case where at least one person was using Shift+drag was as a workaround for a more basic problem - trying to enter notes low below the staff. To me, that's certainly an understandable problem, but I would say it's not a good workaround. For one thing, most people wouldn't think to try this as a solution. But more fundamentally, you shouldn't need to add otherwise-unnecessary space between staves just to get note input to work better. Adding space should be about actually wanting space in the finished score. So I'd rather see that problem solved differently, and am thinking about that now - see #185056: Inability to enter the last note E with the mouse in Guitar + Tablature template. .

Meanwhile, regarding Shift+drag, I still suspect that the original use of adding extra distance between staves throughout the score is unusual enough that it would be a mistake to reimplement this command just to do that. I think it would be much more valuable to many more people if Shift+drag did one of two things:

1) automatically created a spacer and then started adjusting that, thus adjusting the space just within that system


2) in continuous view only, to create extra space between systems for lyrics since we don't do that automatically, but did this in a way that didn't affect page view since the adjustment would be neither needed nor wanted there

I suppose there might be a way to do both of these - doing 1) in page view, 2) in continuous view.

But again, in order to truly understand what the best way to proceed is, we really need more feedback - of those people who used that feature in 2.x and miss it now, what did you actually use it for, specifically? It's crucial we understand that to see the best way to bring some version of it back.

It was also the immediate and quick way (again, I repeat these words) to add distance between two staves, rather than continuously going through the menu Format/Style/Staff distance.
Via the menu you spend at least a few seconds. With the Shift + Drag shortcut, it's one second! I didn't know that shortcuts, at least this one, were not welcome anymore.

But that's the thing - it was never the some as changing "staff distance" - ti was the same as "extra distance above staff". Totally different settings. Staff distance - which controls the distance between all adjacent staves - is indeed at least somewhat common to want to change, but Shfit+drag never did that. It only changed the distance above/below a single staff, which is something most people would do only very rarely. The main use case for this is in large ensemble scores, like in an orchestra where you want a little extra space between the winds and strings. My sense is people were missing this, thinking it was the same as changing staff distance when it isn't, or the same as adding a spacer when it isn't.

So, again, wouldn't it be better if it actually did what people wanted it it to do, instead of what it actually did, which I believe is contrary to their wishes most of the time?

That's why it so crucial we understand, with example drawn from real world usage, how people were using it. That we we can understand if people truly wanted it to change "extra distance above staff" or if they would actually have been happier with it changing staff distance or adding a spacer. In other words, I want to make it better than before.

I think I've written this before, but based on my usage, my preference is definitely to add a spacer. Often I would want extra space when, say, the upper part has a low note with multiple ledger lines and it coincides with some text above the staff of the lower part. Automatic spacing just doesn't make enough room in situations like this — it's not that the text from the lower part collides with the low note from the upper part, but because of how closely squeezed everything is, sometimes it's not clear which staff the text belongs to.

In a lot of cases the ideal spacing between staves varies from system to system, and depends on the density of the music, presence of ledger lines, presence of different kinds of text, whether certain parts are hidden, etc. The automatic spacing is great and does a pretty good job, but I really frequently feel the need to adjust the spacing of one or two staves within a single system.

I guess the biggest reason I think it should be a spacer, instead of a global setting that applies to all systems, is that you want the shortcut for a situation where you have to do something over and over again. In my experience, I have to reach for spacers pretty often, and this would make that process a lot smoother.

(So I guess I agree with Marc. Also, I think your proposal for different behavior in continuous view makes a lot of sense.)

Thanks, by the way for all your efforts and attention to this. I know it's a juggling act between the needs of many different kinds of users.

Yes, thanks, that is definitely my sense as well - use Shift+drag for the most common operation, not the less common one. I really think when all is said and done, adding spacers is probably 100 times more common that adjusting staff distance, and adjusting staff distance is probably 100 times more common than adjusting extra distance above staff. So to me wasting a useful gesture like Shift+drag on extra distance above staff as was the case in 2.x seems a really big mistake. That said, adding a spacer is somehow easier already than adjusting staff distance in the dialog, so in that sens there is something to be said for making adjusting staff distance easier, even if it's the less common operation. Of course, we could do something really crazy like have Ctrl+Shift+Drag for that...

In reply to by Marc Sabatella

For what it's worth, having ctrl-shift drag do staff distance (and maybe even alt-shift drag doing extra staff distance) doesn't sound crazy to me. Unless there's a need for those shortcuts for something else, I can't see how it hurts. And also, these are the kind of things that are best done with immediate visual feedback, rather than changing numbers.