Make adjusting distance between individual staves easier.

• May 9, 2020 - 09:58

So this one brunches off of this bigger topic:
https://musescore.org/en/node/305133#comment-998294

Argument:
one of the main reasons for such a feature would be the fact, that with the modern music engraving the spacing between individual staves and systems, is often not the same. Wether Big-band charts that "suffer" from relatively tight vertical spacing (in landscape paper view)., or piano music, or other situations. Often it is necessary to save some millimetres from the staves, that can have less spacing, in order to be able to increase the spacing between the staves, or systems that really need space. Also often its a matter of aesthetics and readability, to have a tighter spaces between the instruments of the same groups/family (for example orchestral score), and have more space to visually separate them from the instruments of other families. All in all, this is something that a good looking score will have considered.

Spacers are doing their job, but firstly, it would be good to be able to create a stave spacer with the keyboard shortcut. Once the spacer followed by adjustment of the the distance with the arrow keys.
Secondly often there is a need to adjust space between individual staves throughout range of systems, or even the entire score. So I imagine an additional type of "spacer(s) for selected range of systems" that would be linked together. Another type that could be helpful is the spacer for adjusting the spacing between multiple staves vertically (for one system as well as for many)
How difficult would that be?


Comments

  1. There is a desired to enable shortcuts for all palette elements, thus this would then also work for adding spacers.

  2. For adjusting space for the whole score, use the "extra distance above staff" option in the staff/part properties. This perfectly allows for the "group spacing" you mentioned.

  3. Spacer for a range of systems. This is one that is currently not possible I think. So currently the only workaround is to add spacer to each measure of those systems and manually set their length.
    What would really help here is the ability to select spacers within a range, then using the inspector to change their length all in one go (this does work when selecting all spacers in a staff).
    I've filed #305178: Spacer: Select all similar elements within Range for that, so perhaps this can be made possible in the future.

In reply to by jeetee

Thank you.
"What would really help here is the ability to select spacers within a range, then using the inspector to change their length all in one go (this does work when selecting all spacers in a staff)."
Ok in that case how about the ability to create multiple spacers for the range of selected systems at the beginning of each system at once? Would that be possible?

In reply to by jeetee

Sorry, have some repeated messages there. The difference is, that the spacer for every measure is a bit of eyesore. And as i mentioned below they don't actually work, as i' ve tried. Only the once at the beginning of system actually are doing something. So why having them everywhere, when one per system is enough

In reply to by jeetee

If there is no way to make a multicpacer, how about the ability to create multiple spacers at the beginning of each selected system at once? Would that be possible? Right now if you try to do that it creates a spacer for every selected bar, and they are quite useless, since they don't actually work. You can only use the spacer at the beginning of each system to adjust the distance.What else would be really convenient, is that once you create multiple spacers, they would remain selected, so that you can start moving them right away, without having to go to inspector .

In reply to by antonjazzsax

they are quite useless, since they don't actually work. You can only use the spacer at the beginning of the system to adjust the distance.
That is simply not true; add a spacer to a measure at the middle of the system and it'll work perfectly.
Furthermore, a "system" is a fluid thing; when a measure before widens, it can push measures following it to the next system. How do you see the spacer consistently remain on "it's system" when the measures that make up that system can flow freely between systems.

And if your system somehow is "fixed" (a concept MuseScore doesn't have), then what's the harm in having those spacers on every measure of the system if it makes adding them faster and changing them would be possible within a single selection?

That is way spacers are added to measures and not to systems. Because in the normal use case you'd only use them to create room between specific measures (for example dynamics from the Tenor line in SATB coming too close to lyrics of the Alto line).

*What else would be really convenient, is that once you create multiple spacers, they would remain selected, *
There I agree. But I also still think that is true for other multi-add elements; for example when adding articulations to a selection, it also only selects the last of them. So the issue is not specific to spacers, but any element added to a range selection via the palette.

In reply to by jeetee

"That is simply not true; add a spacer to a measure at the middle of the system and it'll work perfectly."
It does work, when you create a single spacer in the middle of the system, but when I range select few systems and add the spacers to every bar like described, the middle ones aren't actually functional. A bug?

"for example when adding articulations to a selection, it also only selects the last of them."
I'm note sure I follow you here. How do you mean adding articulations to selection? via the inspector?

"Furthermore, a "system" is a fluid thing; when a measure before widens, it can push measures following it to the next system. How do you see the spacer consistently remain on "it's system" when the measures that make up that system can flow freely between systems."

Well for me the real question is, why even having staff spacers to be attached to a specific bar? They will do the same thing, wherever they are, so why not having them attached to the beginning of a system per se. ?
Just like a clef? But I guess that is part of the "not possible right now" answer. Is it? Anyway spacers per bar would be slightly less elegant (since they are visible), but a working solution, no doubt. As to the selection, I find it better if they would just become selected right as you've created them, for immediate manipulation

In reply to by antonjazzsax

A screen capture to show you that in the current stable release (3.4.2) spacers do work, regardless of how many there are and where in the system they are placed:

305171-spacer-in-the-middle-of-a-system.gif

How do you mean adding articulations to selection?
Just the same as adding anything else to a selection, by pressing the element in a palette.
Again a screen capture to demonstrate:

305171-add-element-to-selection.gif

So again, having added elements being selected is a feature request I support, but the use case is applicable to all elements, not just spacers.

That last screen capture also clearly shows that clefs aren't always only at the start of a system, but that's just beside the point you're trying to make.

The reason for spacers to be attached to measures is that (at least up till now) the intended use case for a spacer is to affect spacing to avoid or force certain collisions not handled well by the automatic system. As collisions are content dependent, and content is retained within measures, it makes sense that fixing those desires is specific to a given measure.

Furthermore, again; a system is not a fixed thing, measures flow quite freely among them.
So let's consider the next scenario:
You have 5 measures on a given system (without an explicit system break at the end) and add the "system spacer" to that system. I now add a system break after the third measure.
It moves the last two measures to a new system and moreover the 6th and 7th measure that used to be at the start of the next system are now appended into the same system.
Which spacer should now be in effect where?

In reply to by jeetee

Thank you for your demonstration. I got it. About middle spacers, that might be a bug that is reproduceble at my specific score setup. I'll send you more details on that later.

Yes added selection would be of a big help.

About the "system spacer". My comparison was not exactly accurate. Of course you may have a clef anywhere in the system. However on all consecutive systems it will always appear at the beginning of the system (until changed again). So that means that if the system got stretched or squeezed the clef "technically" will appear at the different bar, than it was before, but always at the first bar of the system. No? Could not that be an approach for spacers? Like always first and last barline of the system? I'm not familiar with how the clefs behaviour is achieved code-wise, so I'm just imagining. However That might not be necessary , and maybe not worth the fuss, for sure. What I mean is, it would be good not to have those spacers buzz around all the time. It just looks neater. One thing I've experienced is at a certain volume of music editing, all those hidden elements become distractive. You end up missing some small things here and there, because the actual printed music looks visually different, than in the UI. Not a big deal, but i have to say I really appreciate how little of that hidden clutter is in the musescore compared to other programs ive used. Maybe the spacers could be set completely invisible, and only appear once the bar is selected?

In reply to by antonjazzsax

For the system spacer. I think the thing I'm most struggling with is the actual use case, what purpose does it serve?

For some reason that spacer should be linked to a system and not a specific measure (this is already a curious case to me). Currently all system headers are auto-generated, but there are some properties that can be influenced (like making a clef invisible). Though in reality that property seems attached to that specific measure. See this screencast:

305171-system-header-visibility.gif

So let's assume a system spacer is included to MuseScore, chances are it would act in a similar way. As soon as the system changes and the first measure is no longer the first of the system, it'll likely disappear. After all, the layout has changed enough so that this spacer is likely no longer valid anyway. Or it somehow is moved to again appear at the start of the system (now a different measure).
But what then when the system is split, should the spacer also apply to the new system? Is that only the case if you apply a manual system break, or also when an automatic break occurs due to change of contents?

Coming around to the next part I find hard to grasp. If each system of a certain staff needs that spacer, what are the chances it would need the same value? Because if all of those need the same value, why not change the style setting or the extra-distance-above-staff of the following staff?

And if all of them need a different value, then how would this save any effort over adding them to the starting measures and giving them those same different values each?

In reply to by jeetee

Thank you. Maybe I was a bit too attached to my ideas about spacer. Right now it is actually ok as it is (after some consideration) and shortcut for creation plus selection should really help the practical aspect. However there are some other considerations that came to my attention, after your examples:
Regarding the stretch/squeeze behaviour. It is true, that if a measure containing the spacer at the beginning of the system gets displaced to another system, the custom spacing gets lost. However it is also true for use cases as it is now. If you create a single spacer somewhere manually, introducing a system break at the later point might cause the same unwanted result. So as of now you actually NEED to create bunch of spacers for that not to happen, which is something that might not be desired. So this seems to me a bit of a drowback of staff spacer on general. What i think could be a consideration for the future though: Why not to have staff spacers as invisible objects on all staves and measures at all times? So that when you select a system you just need to move that point of a spacer up or down. In that case all is needed is a sleek way to grab the "handle" of that spacer. However I don't know, how good would that be in terms of keeping the code "lightweighted". So far That is it from what i would think of. Otherwise the current solution works (except for that strange bug that i saw in my score)

In reply to by antonjazzsax

And if you find those spacer lines (which are invisible in all exports etc, MuseScore only shows them in grey so you can interact with them) to be too visually cluttering; consider toggling "View → Show Unprintable" and you won't see them anymore.

I think there are many opportunities to improve certain details of the behavior of spacers, but I also think that perhaps for the use case that most of this seems to be focused on, spacers aren't the right tool to begin with. If the goal is to get an even bottom margin in cases where there is a single system on each page but the systems are of varying heights, I'd much rather see a more direct way of getting that. much as we already have a way of doing that in the case of multiple systems on a page through min and max system distance settings This topic comes up often enough and there are any number of threads full of useful discussion on this, but unfortunately still no actual design proposal coming from it.

There are many complexities with trying to solve this in the most general case, mostly having to do with issues of MuseScore trying to juggle multiple decisions - how many systems will fit on this page, how much should it stretch the staves within the system, and how much should it stretch the distance between systems. But I have one proposal I've made that I think covers enough cases to be useful. It's based on the idea that the main case people are concerned about also happens to be the one case that's relatively easy to solve.

If we know in advance there is only going to be a single system on a page, we don't have to worry about whether more systems will fit. Nor do we have to worry about how much space to put between the systems. There are a number of ways I could imagine constructing a system to make this work, but I think the easier is the following:

We could make it so that if a page break is encountered on a page after only a single system, then that system is considered stretchable. We would add a max staff distance setting (either as a style, or a property on the page break, or both), and so for any system thus determined to be stretchable, we stretch it by increasing staff distance up to that maximum exactly the same way we already increase system distance for pages with multiple systems.

So for a big band score, the user would just need to add explicit page breaks to each page and MuseScore would have all the information it needs to achieve the desired end result, not mucking about with spacers required.

Ultimately, we could consider somehow extending this even to cases where there are multiple systems on the page, but then we need a way of prioritizing whether to stretch staves to the max then stretch systems, or vice versa, or some other combination. At that point it starts to sound like more trouble than it's worth and I would turn to spacers, though.

Still, all that said, again, there's plenty of room for improvement with respect to spacers.

In reply to by Marc Sabatella

I think right now there is a functional gap between the global staff spacing e.i, staff properties, when the value determines the distance between two specific staves throught the score and the individual staff spacing on a specific system and measure (staff spacers). Something that would allow easily manipulate the spacing between few systems on the page. FWIW i think by far the best UI solution is "grab-select-drag" approach, where you just pull the staves around for those short sections. Spacers as a unit are somewhat more cumbersome. Which doesn't mean they would not work, but to me they could use some refinement. As far as system stretches through dialog staff properties (if I correctly understood your idea), honestly for a musician, it seems like a bit too much "mathematics". I mean if it's not a global setting, applied to the whole score, you don't really want to bother counting spaces and distance units in the dialog box for such small amount of adjustment. I suspect that's just how typical intuitive musician would feel about it. But that might be just my subjective feel. That's why I thought of "invisible spacers" everywhere, that are at your service for every individual system. In that case I personally would not mind just having that tool for adjusting individual systems

In reply to by antonjazzsax

I'm not sure if I wasn't clear or if you are talking about a different use case than I am. For the user case I am talking about, having to go through page by page and drag staves around would be an enormously more time-consuming and error-prone operation than just setting an appropriate max staff distance, and yes, I am talking about a global style default, just like max system distance already is. it's not complicated mathematics, just plug in a really big number like 999 in one place and you're good to go. Heck, the default could even be something that worked well enough for most cases, so everything would just work right out of the box.

But if you are talking about some case you think would actually require all the extra work of dragging staves, attaching a score and describing the desired result in more detail would help in understanding the suggestion, both why it would be needed and how you would expect it to work.

In reply to by Marc Sabatella

"it's not complicated mathematics,"
I know, I'm exaggerating a bit. No, of course that sound like a solid solution, that would do the job, and system stretching sounds like a good way to do it from user's perspective.
But you should not underestimate, that users are much more prone to taping and dragging things from using their smartphones and tablets. If you give them ability to drag staves around they'll do it with much more enthusiasm, than reading documentation to find out, where that dialog box is, even if it's just one click away. I think that is one of the things that made sibelius such a serious rival to finale at some point, that it would combine solid grids with just the right amount of gui interaction . I myself don't rely on dragging much, since it is not as precise as I would like it to be, but I would still rather grab/select a staff/system and move it around using arrows in small increments. That is best of two worlds for me in terms of "tactility" and precision. So that seems like a fine balance. for the entire score I believe users would be used to adjust numbers, while for a system or two, maybe would rather choose dragging. I believe we are both talking about small portions like mostly 1 system (maybe 2-3) at once on the same page or two. Which would also be ok to do with spacers. Especially if they would be a bit faster to create and remain selected as proposed above.

In reply to by antonjazzsax

I would also say there is something to be said for the idea of not making it easy to do bad things. manually fiddling with staves one at a time is a lot of hard work, it's imprecise, and it probably will be "fragile" in that those same adjustments won't make sense once you make any edit to your score that affects the layout anymore. So really. better to steer people towards methods that are easier and actually work. The trick is to figure out how to do that using easily discoverable gestures. So it's certainly conceivably that, for instance, an attempt to drag a staff could pop up a relevant dialog automatically ("do you want to add space just for this system, or do you want to fill the page automatically", etc).

In reply to by antonjazzsax

Once upon a time dragging staves did something, although something that isn't all that useful in most cases - it adjusted the "extra distance above staff" property, which is something one normally would do once per score at most (eg, to add separation between winds & strings in an orchestra score). A scheme where it automatically added a spacer, or otherwise did something that actually is a common operation, would be nice. I believe this kind of thing is being looked at by Maritn (tantacrul ) already.

Do you still have an unanswered question? Please log in first to post your question.