stave spacing with chords
Hi,
Not sure if this a bug, but automatic stave spacing seems a bit strange in this case (see files attached). I don't understand why spacing is uneven. It seems to be related to the chords.
Kind regards
| Attachment | Size |
|---|---|
| stave_spacing.mscz | 19.53 KB |
| stave_spacing.png | 192.74 KB |
Comments
This looks like a bug to me. I don't see why e.g. the system with the "Fine" is farther apart than the ones above and below it.
Took me a minute to figure it out.
You have your lyrics min bottom margin (Format / Style / Lyrics) set to an unnecessarily large value - well, the value that was the default in 2.3.2, because it meant something different then. Now, it determines the space to the highest element above the next staff. Most of your systems you are getting lucky and there is nothing above the next staff right below a lyric, but a couple of places there is. And then on top of that, you also have very small value for max system distance (Format / Style / Page), preventing MuseScore from adding space to even things out, and also an unusually small value for min system distance.
Solution is to set all of those back to their defaults using the reset button next to the control.
In reply to Took me a minute to figure… by Marc Sabatella
The bug is that when the chord symbol will not collide with the word in a lyric, there is no extra space allocated for the chord symbol and it ends up between lyrics. This is similar, and probably related to the bug (I'm not going to look for right now 'cause it's midnight) where melismas are ignored for collision avoidance.
In reply to The bug is that when the… by mike320
This isn't a bug, it's part the whole "skyline" algorithm - there is no collision, so no reason not to allow this. Sure, it looks silly here, but that's mostly because the style settings are so badly out of whack. Using the defaults you wouldn't see this on this score.
It's possible to get with even with default settings, but you normally wouldn't want MsueScore being so eager to add space. Consider, what if it were only one lyric below the staff in the first bar of a system, then one chord symbol above in the last bar - should there really be space allocated so the horizontal plane of that one chord doesn't cross the horizontal plane of that one lyric? Only when it results in situations like this would you maybe subjectively decide to add the space, and a spacer will do that nicely.
That said, I could imagine some new style setting that allowed you to specify some max distance between lyrics where we would treat the space between the lyrics as part of the skyline and not let anything cross into it.
In reply to This isn't a bug, it's part… by Marc Sabatella
This
![Chord in lyrics.PNG]( "Chord in lyrics.PNG")
is not acceptable. It's a bug. No one wants their chord symbols in the middle of the lyrics. All I did in the score is what you suggested, reset the distances to default.
In reply to This [inline:Chord in… by mike320
I think you missed some of the distances. If you reset everything I said, you get this instead:
Again, if you go out of your to ask for unusual spacing, you will get unusual spacing, but the defaults won't do that so much, and skylines in general (which is what you are seeing here) are an important feature, not a bug at all.
After all, you most certainly do want it possible for a chord symbol in one measure to happen to cross into the plane of lyrcis if there aren't lyrics nearby:
Adding more space by default would be counterproductive and would rightly result in users complaining about too much unnecessary space being added (something they are already complaining about as it is). And yet, clearly, we don't want this, either - and this much is possible with default settings:
So, it's a valid suggestion to come up with an algorithm to decide when to not let the staff below cross the plane at all, versus when it is OK. That's why I suggested some sort of max distance that content from below is not allowed to cross into. I don't know, that's probably too simplistic. Coming up with one algorithm to actually do what is wanted all the time is difficult, and so far we're settling with doing what it right 95% of the time and allowing you to add spacers the other 5%, which still seems valid.
Thanks!
I'm always impressed by the reactivity and efficiency of this forum :D