fretboard diagrams don't allocate extra space on any non-top staff
- take the promename example
- add another instrument, below the piano, e.g. a guitar
- add a chord symbol to any note/rest in the 2nd system of all 3 staves
- add a fretboard diagram to any other note or rest in the 2nd system for
- the guitar staff
- the bottom piano staff
- the top piano staff
- the guitar staff
expected behavoir:
all fretboard diagrams allocate extra space above their staves and the chord symbols stay on the same distance above the staves
actualy behavoir:
- the fretboard diagram on top staff allocates extra space and the chord symbol stays in correct distance to staff (good)
- the fretboard diagram on the bottom piano staff allocates extra space (good), but the chord symbol moves up (bad)
- the fretboard diagram on the guitar staff does not allocate extra space and so it collides with the staff above (bad), the chord symbol stays at its distance (good), but moves up (and collides with the saff above) when a fret diagram gets added to the bottom piano staff (bad)
Comments
See also #24349: Set the size of fretboard offset text as part of the style
and #24538: parameter for distance between fret diagram and chord symbol doesn't do anything as well as #24494: FretDiagram : make the vertical offset a user adjustable parameter
The other issues mentioned above should now be fixed, my PR got merged.
FWIW, I am pretty sure the code that deals with the allocation of space is the last 6 lines of FretDiagram::layout() in fret.cpp. I suspect somehow the calculation is mixing up offsets from top of staff versus top of system, so distanceUP is being set incorrectly. Either that or it is being interpreted inconsistently where the value is finally used. I'd start by seeing if you can sort that out. Maybe see what value is being set for distanceUp in the case that works, and try using that value for all cases to see if it makes them work too. If so, you'll know the problem is with the calculation.
I think I found the Problem, indeed in the place you mentioned (and I mentioned earlier as being suspicious):
Just dividing system->staff(idx)->y() by idx+1 in fret.cpp line 313 seems to work quite nicely.
Chord Symbols not in top staff, with fretboards in their staff, still jump all over the place during entry and end up in wrong spots after.
the jumpy chord symbols Problem seems similar to #24742: cursor jumps down and up during chord symbol entry on non-top staves
See PR #721
Remaining (not new!) issue:
For staves with fretboards the chord symbols' edit box jumps up (too high, final output) and down (correct position, but just during input), in a similar fashion to befor fix #24735 and they are still showing up too high though (by 9sp on 2nd staff, 16.25sp on 3rd 22.75 on 4th, etc.)
Should be fixed in 9a054060eb
Not quite there yet:
![fret.png]( "fret.png")
The top staff looked better (and correct) before this, now it has the chord symbol not above the fret diagram and reserves less space than before (and not enough IMHO, like all the others too)
The middle one has the chord symbol without fret diagram placed to high, the bottom one has all chord symbols placed too high
That fix does not allocate any extra space for fret diagrams on top staff, but a fret diagram on a 2nd staff allocates extra space on both the 2nd and the top staff!?
A fret diagram on a 3rd or subsequent staff allocates space only above that staff.
Oh, I see. a fret diagram on 2nd staff appears to reserve space above top staff, if the legitimate allocation above 2nd staff causes a system to move onto the next page.
I am looking at issues relating to this, although I am not sure what the expected behavior should be in certain cases. The example in #11 above is a good one to use as basis for discussion. I'm going to describe what I think is wrong, you can tell me if you have different expectations.
For the top staff, I think the problem is the B overlapping the fret diagram.
For the middle staff, I think the problem is the A & C being too high. That is, the A & C should be on the "normal" chord baseline, not aligned with the B. I suppose some might expect otherwise, but I also suspect in the real world, these cases are not often mixed.
For the bottom staff, the problem is the B too high relative to fret diagram *and* the A & C being now *way* too high. That is assuming they should still be on the "regular" chord baseline. If we assume that A & C should algin with B, though, it's still off - they are not aligning with the actual position of the B or the position where B should have been,
Beyond that:
Currently, adding a fret diagram to the top staff of a system does not cause extra space allocated - the extra space is purely within systems. I have no plans to change this.
Currently, adding chord symbols does not cause extra space to be allocated, with or without fret diagrams. I'm OK with this, but suspect some would prefer space allocated as it is for lyrics. This subject has come up before. At this point, I think it would be a bad idea to change this behavior for all scores, as it would alter layout of 1.3 scores. i think if done, it should be optional, defaulting perhaps to On for new scores (even that I think is debatable) but Off for 1.3 scores. For now I have no plans to touch this.
Right now, my plan is just to fix the relative positioning of the chord symbols and fret diagrams.
https://github.com/musescore/MuseScore/pull/964
This implements what I described above. That is, chord symbols with associated fret diagrams always display the same distance above the fret diagram and chord symbols without associated fre diagrams always display the same distance above the staff, no matter which staff. Extra space is always allocated for fret diagrams but never for chord symbols, which is why the chord symbols above the bottom two staves collide with the staves above. So you'd still need to add extra space between staves yourself, either globally for the score by dragging the staff down or system by system using spacers.
Fixed in 4f42fb0d82
I would prefer chord symbols to allocate extra space, just like lyrics and fretboard diagrams, and like you said, optional, default off for 1.x scores and on for 2.0.
I think that seems fine down the road, but I'm not sure it makes sense to add this feature right now. BTW, there are fundamental problems with thenway fret diagrams allocate the space - see #25941: Fret diagram in staff > 0 are offsetting slurs and ties. I'm not convinced we won't have to remove the feature that allocates extra space even for fret diagrams. Now that it is so easy to add extrs distance distance between staves score-wide, I'm not thinking it will be any great loss.
Adding this space allocation for chord symbols after 2.0 would conflict with making it behave differently on 1.x vs. 2.x
I'd still want this optional (I personally would probably keep the option turned off), controlled by a style option. Scores create in 1.X or 2.0 would have the option turned off for sure. Scores created in what release this feature were added in would have the option in whatever state we decide to make the default.
Yes, that'd work too
Automatically closed -- issue fixed for 2 weeks with no activity.