Cannot add custom lines spacers to custom palette
Reported version
3.0
Priority
P1 - High
Type
Functional
Frequency
Once
Severity
S3 - Major
Reproducibility
Always
Status
closed
Regression
Yes
Workaround
No
Project
In version 2 I had common sizes of spacers in my Breaks and spacers palette to make setting line spacing easier. It is impossible to add a custom spacer to a custom palette in version 3. Any attempts and ctrl+shift+drag moves the entire screen.
Fix version
3.2.0
Comments
Huh, wouldn't have known that was possible. Nice feature, would be nice to have it back. But - probably not as important given automatic staff spacing now?
In reply to Huh, wouldn't have known… by Marc Sabatella
With the messed up spacing in continuous view (the second line of lyrics ends up superimposed on the staff below) I use it to see lyrics in continuous view. I can then get rid of all of them at once in 3 clicks when I'm done with them.
I will point out that the way spacers is implemented in version 3 is very poor. The up spacers only move anything if they are extended to the top of the previous staff. In version 2, the up spacer added extra space above the selected staff and the visible staff above it - period. This also made it much more convenient to have custom spacers that were 1, 2 or 4 spaces tall depending on which was more appropriate for the situation. It is now necessary to have a 12 space up spacer to allow for room between staves with lyrics. I'll get used to the down spaces, but they will still need to be longer than they were in version 2. The palette will be rather interesting to see.
I set a high priority for the lyrics / continuous mode bug, hopefully that will be fixed making some of this moot.
I'm not totally understanding your comment about the difference between 2.x and 3.0. To me the way up spacer worked was a bug, inconsistent with down spacers. Down spacers set literal distance between two staves - a spacer with a height of 12sp meant staves were 12 sp apart. Up spacers set the distance between the staff and some arbitrary point below the previous staff (presumably dependent on the staff distance setting?). The 3.0 model is somewhat better in this respect but since it uses top of staff rather than bottom of staff, it's now always off by the staff height rather than the arbitrary distance below staff that was used in 2.x.
Now, I do get that sometimes you don't to actually set the distance between staves, but instead want to set the distance below the content of the staves. So, you don't way to say, "make this staff 12sp below the staff above", but "make this staff 4sp below the content of the staff above". But a) this is more properly done with a spacer down, not a spacer up (since the reason for wanting the extra space is because of the top staff content - that's indeed the whole reason there are two different spacers), and b) this doesn't invalidate the other use case, so maybe a new spacer type - or option to set on the existing spacer down - is called for.
In any case, spacers shouldn't be normally necessary for this purpose when it comes to lyrics - that's what the "lyrics bottom margin" style setting is for. That's true in both 2.x and 3.0. This style setting works quite literally. Set it to 0sp and the staff below lyrics will sit directly below the lyrics (assuming there are enough verses that you've already exceed the nominal staff distance). So if you want there to be 4sp space between a staff and the lyrics of the staff above, just set lyrics bottom margin to 4sp and be done. I guess you are saying you might want different amount of spaces below lyrics at different places in the same score? In that case, then indeed spacers will be the way to go, and yes, for this particular corner case, the fix to up stapcers ends up being a step backwarsd. But for the more usual cases, the new interpretation more consistent and more appropriate, except for the part about it setting distance to top of previous staff rather than bottom.
The extra space above the staff that happened in version 2 is much preferable to the current action. Your explanation has nothing to do with real world use of the tool. In version 2, if I put the spacer above on a staff with lyrics above it, the space between the last line of lyrics and next staff stays consistent and there is no need to adjust the spacer if you add more lyrics. I may need to adjust the space if I put a higher note on the lower staff, but that's to be expected since the space it above the actual staff. The down spacer acts the same in both versions 2 and 3, and that's fine. In version 2 you had two different tools, in version 3 you have one tool with two looks.
There are mutiple real world usages. The whole reason the Up spacer was introduced (previously there was only Down) was to cover cases of additional space needed above a staff because of things like chord symbols or notes high above the staff. Yes, you could place a Down spacer on the staff above, but this wasn't really the correct thing, and it didn't work if the staff above is actually a different system - well, uit would work until the layout changed such that it was then a different measure above the one with the content causing the problems. It was realized that it is important to attach the spacer to the actual measure with the problem, not some other measure on some other staff or other system.
So in your case with lyrics below the staff, the right place for the spacer is on the staff with the lyrics, and it should be a Down spacer. The Up spacer, again, was not originally designed for that particular purpose. it's just kind of coincidence it ended up working that way. You'll still have the same problem - even in 2.x - if the staff above is on another system and the layout changes such that the measure above where you placed the spacer no longer causes a conflict (or causes a worse conflict).
So again, I'm not disagreeing that a way to set a variable lyrics bottom margin could potentially be nice. I'm just pointing out that is really a different use case form what spacers were actually designed - and are commonly used - for.
Maybe someone besides marc has an opinion
Probably best to discuss this further in the forum, since it really is only tangentially related to the issue at hand, and we will want input from other users of spacers.
Spacer up is available since quite a while...
It's available, yes, but you can't add customized sizes to a custom palette. That's what this issue is about.
Also, the semantics has changed - from giving distance to the "bottom margin" of the staff (including lyrics etc) to giving distance to the staff itself (which is what spacers down do). That's what this digression is about. But it remains the case that it's better to discuss the digression further in the forums.
Still an issue, presumably with an easy fix, and now with increased focus on usability of continuous view, I'm raising the priority. Simply put: when adding a custom spacer to the palette, we should preserve its height. Actually, I suspect we are, but are setting it to a default when adding it to the score.
Meanwhile, some time ago I actually changed the behavior of the up spacer to be more compatible with how down spacers work: setting distance to the bottom of the staff above, not requiring you to go all the way to the top of the staff. See https://github.com/musescore/MuseScore/pull/4722. having studied the code extensively in order to make other fixes in that area, I am now confident that this is way it was really intended to work all along, and how most users would expect. See for instance and #99686: Staff spacer up pushes staff away at a distance. See also my comment in the PR that changed this:
"There was some doubt in my mind at first whether this was a bug or a deliberate design change. Now that I understand this code better - and also observe it works as expected between systems but not between staves - I can see clearly this was a bug all along. Unfortunately, it means people who had worked around this by making their staff spacers up unnecessarily tall will need to readjust them."
The problem in version 3 is that it's impossible to add a spacer to a custom palette. You can't even ctrl+shift+drag them to duplicate them like everything else.
I've gotten used to using the down spacers rather than the up spacers in version 3, so I'm less concerned about that issue. Once I can drag custom spacers to custom palettes, I'll be happy.
Oh, I see, you even described it in the original post - Ctrl+Shift+drag actually drags the canvas when clicking a spacer. It looks like the code in ScoreView::cloneElement() specifically disallows it for spacer (along with notes and vertical frames). It appears from the code this change was an accident, the intent was to allow spacers to be cloned even though they aren't otherwise considered movable, but in a cleanup of those lines it got turned around. I imagine it would still works, then, if I change to something more consistent with the original. I will test this theory and submit a PR if that does it.
It works indeed, but the palette looks terrible - there is no code to scale things to fit in their cells. Same in 2.3.2 though. Any opposition to me capping the display size in the palette? Or are you typically using the scaling factor to somehow differentiate them?
Also, if you add a spacer (using an existing version of MuseScore, I mean) to a small staff, it's clearly not right. But, what is right? If you have set a spacer to 12sp, say - should that be 12sp as measured by the score spatium, or I scale it down when adding it to the staff? Seems if you're using this for spacing of lyrics etc, scaling makes sense, but if you're doing it for ordinary page layout purposes, you might want it to not scale.
In version 2, I normally had 1, 2 & 4 space up spacers added to my palette and they were proportionately sized so I could tell which was which. These just added that much space above the staff. In version 3, the spacers are typically 9-12 spaces tall since they are absolute in length, but I will remove the useless 3 space spacers, so I guess as long as there is some difference between them it won't matter.
I can't think of a good way to automatically figure out a way to scale, so with what I have right now, everything will just appear a max of 4sp tall by default. But you can then customize the scaling, or just give the cells names that work as tooltips. That's the best I can think of for now.
It's not ideal, but at least there's a decent workaround.
https://github.com/musescore/MuseScore/pull/5067
In reply to https://github.com/musescore… by Marc Sabatella
In 2.3.2 you could copy the spacers with Ctrl+Shift and drag.
This functionality doesn't exist anymore in RC3.1 You move the Canvas instead.
OS: Windows , (32-bit):2.3.2, 4592407
OS: Windows 10 (10.0), (64-bit): 3.1.0.7011, 8b1a7dc
In reply to In 2.3.2 you could copy the… by MichLeon
Sorry, to be clearer: in 2.3.2 you can copy the spacers while working on the canvas.
A good thing e.g. when editing the first page of a score containing 2 systems of say 8 instruments
compared with other pages which can contain 3 systems.
My PR allows for the copying as well.
In reply to My PR allows for the copying… by Marc Sabatella
Thank you very much for this! And for the incredible stamina whith which you sustain the development of the program together with the other people I read about. In the context of e.g. FOSDEM.
Fixed in branch master, commit 0fe61aa8f8
fix #279117: allow custom spacers to be added to palette
Fixed in branch master, commit b33466c7fc
_Merge pull request #5067 from MarcSabatella/279117-spacer-palette
fix #279117: allow custom spacers to be added to palette_
Automatically closed -- issue fixed for 2 weeks with no activity.