Shift+drag doesn't move staves anymore

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.

"So I'll leave this open as a suggestion to add back at some point."
+1

"... 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

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.

Delete

Came up again in: https://musescore.org/fr/node/283680

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.

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?

The more I think about it, the more this seems to be a particularly big issue with orchestral scores, since there's so much information to squeeze on the page, and adjusting spacing is a way of helping to make that information parse better to the eye.

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 (https://musescore.org/fr/node/299593#comment-971369) 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."

No doubt, but my point is, maybe it be cooler is this instead added a spacer?

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?

Again in: https://musescore.org/en/node/276141#comment-1010481

Disagree.
And just for recall: Priority: HIGH

Do you count more than 5?

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!

Doesn't invalidate my statement

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

or

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...

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.

I am relaunching this thread/issue again because unfortunately, it is sometimes so difficult to make oneself understood.

So let's take a common use case (and really very frequent in my practice)
Open this score: Valse_Marine.mscz

The Tab is a "Simple" type. You want to check what it looks like with the "Common" type, eg via the Instruments dialog. You get a cluttered result, lacking visibility, with stems colliding. Bad.

With version 2, a simple Shift + click was enough to separate the two linked staves and examine the score and the two staves with comfort.

So, my question is simple: can you please tell me another way, as intuitive, fast and simple, especially when you repeat these operations tens and hundreds of times, to do it with version 3?

In MuseScore 2, what the drag did was automatically increase “Extra distance above staff” in Staff Properties - so it added space not just to this one system, but to all systems. If that’s the result you want, the way to do it is set “Extra distance above staff” via staff properties. Only once per score, and if you then save that as a template, only once period, because you can then reuse the template.

As the discussion is trying to make clear, for most people, adjusting a single system is far more common than wanting to make the same adjustment to all systems simultaneously. That’s why I’m proposing we introduce the default operation specifically to do that - to add a spacer, basically. But then there would be no reason we couldn’t make some other command like Alt+Shift+drag to do it score wide.

These are the kinds of things being looked at for MuseScore 4.

Sorry, but all this is irrelevant here.

I said again : the use cases are when you switch continually between linked staves (or not) from a « simple » to a « common » TAB staff type (with stems and beams display).

The attached file above « Valse Marine » is the perfect example. These are scores that you download, for example from musescore.com, or guitar pro, or other formats, in short, it's infinite.

But this can also be the case for new scores, where you may have to choose between a simple or common staff type display, and therefore have to examine, compare advantages and disadvantages etc.

In these cases, the model is not relevant (the goal is not to have a model, but to work  on a score, to switch quickly from one display to another ie Simple vs.Common, and vice versa)

The spacers are not more, since I want to add distance between all staves, of course.

Via this Staff properties, it's just a pain for each score, and each time you want to ompare the two types of Tab staff, to open this dialog, handle the distances, Apply to see if it goes or not. In short, it's so time-consumer and boring !

And finally, the automatic placement, which is supposed to avoid questions of this order, obviously fails in these cases. Just have a look at the picture attached above (and below) : the fact that the stems of the standard staff cross and obstruct the vision of the stems of the TAB staff in common style (staves are cluttered, confused) is surely not the good result we are hoping for.

That's why this Shift + Drag was a feature so useful in version 2 when switching from one display to another, in a flexible and immediate way.

What I can think as an alternative, at least, would be to restore this Shift + drag function, but to make it, for “Extra distance above staff”, a shortcut (predefined, or not) in the Preferences ?

I do believe I understand. What you are saying is that switching between one tab style and another is common operation for you - not just once per score, but possibly many times per score. I have never heard anyone else say that, so I'm still assuming this is uncommon overall, compared to the thousands of people who have need to change staff distance for one staff only often and ask about this on the forums multiple times per week. But anyhow, yes, it would be nice to make your particular use case of wanting to change distance score-wide easier as well as as making the more common use case of wanting to change staff distance for a single system easier. And that is precisely why the proposal I made should satisfy everyone - Shift+drag to do the thing most people want most often (add a spacer and thus affect the current system only), Alt+Shift+drag do the less-common-overall thing you are describing here (change "extra distance above staff"). Everyone wins, yes?

But actually, I think we can do better still. If it's truly the case that every time you switch to a different tab style, you also want a different staff distance, why not just make that fully automatic? If the "extra distance above staff" setting were part of the tab style itself, then every time you changed tab styles, the staff distance would adjust automatically, no need to drag anything. Wouldn't that be even better?

BTW, regarding automatic placement - it's on purpose that extra space isn't allocated in your example, because there is no true "collision", only a form of "overlap". That is, autoplace deliberately allows stems from one staff to extend into the space between stems of another staff, as long as they don't actually touch. And very often, this is what you want, as a single stem extending above one measure doesn't really interfere with a single stem extending below another measure. But in cases like your picture, it does indeed get confusion.

I believe it would be possible to extend the autoplace algorithm in a pretty simple way to add a new style setting to control how close we would allow those stems to be. In technical terms, it would widen each "shape" when adding it to the "skyline". This could also help with a similar issue involving lyrics.

It doesn't matter whether it's once or twice or more (by the way, you don't necessarily enter a score in one go, in one session), that's the principle and immediacy of the shortcut.
By the way, I don't know how you can say that thousands of users do something and only one other would do something else, besides, if that were true, this possibility would not have been implemented by Werner in version 2.
Let's move on.

"why not just make that fully automatic? If the "extra distance above staff" setting were part of the tab style itself, then every time you changed tab styles, the staff distance would adjust automatically, no need to drag anything"

Of course, that would be ideal, theorically. But the "default" would have to be well calibrated, and adapted to all situations (and that, I don't know). So the shortcut Alt + Shift + drag would be perfect, I think.

"I believe it would be possible to extend the autoplace algorithm in a pretty simple way to add a new style setting to control how close we would allow those stems to be. In technical terms, it would widen each "shape" when adding it to the "skyline". This could also help with a similar issue involving lyrics."
Interesting, too, and all the more so if it serves another function as lyrics.
(but the shortcut always has my favor, simply because I keep control of what exactly I want to get as a result)

To me it is important to establish the most common use case, because that is how we decide which behavior should be Shift+drag and which should require Alt as well. To me it seems "obvious" from the thousands (literally, I would gyuess this has been a couple of times a week over the course of many years) of questions on the forum about how to add space to a single system, compared to the relatively small number about how to add space between two specific staves on all systems (which is asked about more like once every couple of months). If you truly believe there have more requests about the latter than the former, it is certainly possible I have somehow missed them - maybe they only happen on the French forum? - but anyhow, I guess this is the sort of question best left to the usability / design experts like @tantacrul to decide.

But the bottom line is, again, I would like to see both behaviors made possible. To me it really is just a matter of which requires the Alt and which does not. I want to help the most users I can, so I want to see us decide which case is more common and make Shift+drag to that, and have Alt+Shift+drag to the less common one. Bot once more, I want to see both become possible.

Probably between my other two proposals - having "extra distance above staff" be set automatically by different tab styles, and having a way to automatically prevent the sort of overlap shown in your example - I like the second better. Having a pre-determined "Extra distance above staff" only makes sense if we also know what the staff distance itself is. For scores with a large staff distance, we don't need any extra distance. And of course,e it only solves that particular case, not any similar cases that involve, say, piano music, or lyrics.

" I want to help the most users I can, so I want to see us decide which case is more common and make Shift+drag to that, and have Alt+Shift+drag to the less common one. Bot once more, I want to see both become possible."

Okay, so let's go. It doesn't matter (to me, anyway) whether it's one shortcut or the other. But above all, let's not to remain indefinitely in indecision, waste any more time wondering what would be better, just do what you think is best, more common vs. less common, and that's it.

I've brought it up in our internal design chat to make sure it's done in a way that fits in with the future plans regarding how page layout will work (which I understand will be changing more significantly in the future).

Related to #311174: [EPIC] UI/UX issues and suggestions