Make it possible to add spacers to all selected staves and filter selection by spacer

• Aug 17, 2019 - 00:25

Sometimes one needs to add spacers to all staves in order to increase uniformly the distance between staves. An example, when hiding empty staves and there is no room for an extra system. Currently one must select the staves one by one and add the spacer.
It would be nice to be able to select all the required staves and double click the spacer from the palette to insert all the spacers at once.

Once the spacers have been added, one needs to select them all so that with single change in the inspector, the correct distance can be achieved. Currently one has to select them one by one since spacers are not listed in the selection filter.
It would be interesting that such filter were available.

Combining both features, it would be easy to change the stave distance in a few steps.


Comments

Another workaround would include adding one spacer and resizing it then using Ctrl+Shift+drag to clone and copy the to the next lower staff, this would fill a system with spacers fairly quickly.

Agreed that applying to multiple staves on double-click makes sense, I'd call the failure of this to work a bug. Also the failure of right-click / Select All Similar Elements in Range Selection.

In reply to by Marc Sabatella

Your workaround seems a good one but at least on my system each of these operations freezes the machine for about 6 s. I find the fastest way is to select the first staff, double click on the palette, then blindly select the second (no echo of the selection), double click, and so on. It is not much faster, but at least the manual part can be done faster while the computer is working.

In reply to by Marc Sabatella

I don't think it is the case. Doesn't happen with short pieces or with other programs. I generally have open some other programs, such as Total commander and Notepad++, sometimes Word or Acrobat, sometimes Firefox and Thunderbird (inactive while using MuseScore, or it seems so), and the Avast antivirus that is running at the background, but I've tried closing all those programs and even disabling the antivirus for a while. It is the same. It happens with any large score (for instance 200 measures and 30 staves/parts) and it doesn't happen (or the delay is much less noticeable) with short scores. My OS is Windows 7 Home Premium Service Pack 1 and I have 6 GB RAM on an i7 processor.
By the way, I've posted a feature request on saving in the background to avoid freezing during saving, a problem also related to score size (https://musescore.org/en/node/293436)

In reply to by Marc Sabatella

I'm not talking about continuous view but page view. Adding spacers in continuous view makes little sense in my opinion, even if some collisions might occur, because it is only a draft version. I acknowledge that other users may have a different workflow, but my case is about page view. Adding a spacer takes much more time than adding a system or page break. The point I want to stress here is that just adding a spacer never causes a relayout, since the default spacer height (3 sp) is smaller than the default staff distance (7 sp), so nothing changes except the spacer itself. What may cause relayout is resizing the spacer.
Isn't it possible that when adding a spacer there is a hidden chain of events unexpectedly triggering relayout? Why adding a spacer takes longer than adding a system or page break?

In reply to by fmiyara

It doesn't take longer for me, but sure, it's possible something is causing it to in some cases. I do know that the fact the adding it doesn't actually change the layout is irrelevant, we don't know that at the point we have to decide whether the command affects layout or not. In fact, it's only by setting the flag that a change has occurred in this measure that we go through the calculations that would enable us to determin that 3sp is not enough to add space.

In reply to by Marc Sabatella

As I said earlier in other post, adding a spacer alone shouldn't trigger a relayout since it doesn't change anything. Resizing it is what causes relayout. Since relayout is much time-consuming, a test to see whether it is necessary or not is welcome, particularly because the adjustment is generally by trial and error. So one starts to increase the spacer height but until one gets the desired height it may require two or three iterations.

In reply to by fmiyara

That only happens to be true by default because the default staff distance happens to be greater than the default staff spacer size. But we have no way of knowing the specifics of the current situation until we actually commence layout. For all we know you might have decreased the default staff distance, or customized the staff spacer on the palette. And certainly when using the approach I just mentioned where you clone an already-sized spacer, the change happens immediately on adding the spacer. It is necessary to mark the measure as needing layout in order to start the process that figures all of this out. Feel free to customize your palette yourself to add a larger spacer if the extra delay is a problem in your workflow.

In reply to by Marc Sabatella

I imagine the current spacer size and the current staff distance is known the very moment I drop the possibly customized spacer on its target measure/staff, so the software can make some checks before starting the actual relayout. For instance, in page view it is very simple to calculate the new total vertical space to be required after the spacer is inserted since it is the sum of all the staff heights and all the maximum values between current staff distance and the corresponding spacer height (and system distances). If this is larger than the available space so that a system is forced to go to the next page, then a massive forward relayout is required. If not, the relayout affects only the present page, or, rather, the rest of the present page and should not take much time. Besides, the only effect will be to add an extra fixed vertical offset to all elements in the rest of the page. But if the current (possibly customized) staff distance is larger than the current (possibly customized) spacer height, nothing should be done and would take virtually zero time to react (and very little memory out of several GB).

In reply to by fmiyara

Yes, those two of the many factors affecting staff distance are known, but none of the others - contents of the staves determining the skyline. There is nothing to be gained by performing some sort of half-baked partial calculation of the layout. Again, you are really that concerned about the time, just customize your palette as I've suggested. But I really do this know this code pretty well and speak from experience here.

In reply to by Marc Sabatella

Anyway, a preliminary relayout could be performed for the current page. This doesn't take too much time, as confirmed by the example of scores at the beginning of the note entry process (the problem arises after several pages have been completed). If after the preliminary relayout it turns out that nothing has to be sent to the next page, then stop there since none of the rest of the score needs relayout. If for a 100 measure score the delay is 5 s, then a 5 measure page will take about 0.25 s, a much tolerable delay. This would screen out the cases where the relayout is local to the page. By far this is the most frequent case when adding spacers to accomplish alignment of the last system to the bottom (a situation where the excessive delay is critical because massive spacer addition is needed to compensate the lack of a feature that automatically do the alignment).

The solution of customizing the spacer height would solve only part of the delay/freeze problem, the initial space insertion. But most often at least one iteration (and frequently several) will be necessary to find the correct spacer height.

The solution of threading to separate UI processes from background formatting activity beyond what is on the screen would be much more definitive. Maybe most current processes won't be much accelerated, but if the software keeps evolving, as all of us expect, more complex functions will demand more and more background processing, so eventually the decision will have to be made, and it will be easier and smoother if it is sooner than later.

Hello,
I wanted to do exactly the same feature request but I had the good idea to check beforehand if it didn't already exist. And that is the case:). So I strongly support this request in its two proposals: Implementation and multiple management of sptaff spacers.
The workaround proposed by Marc Sabatella does not cause me to slow down even on large scores (W10-1903) but does not seem to me to be faster than my current way of doing things: I bring my page, reduced to 50%, as close as possible to the Break & Spacers palette and I slide the spacer on each staff.
This concerns the implementation but then there is the multiple selection. For the moment we can only select the spacers individually or on a system. It would be very desirable to be able to select them simultaneously on all systems on a single page.
Thank you.

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