Long instrument names appear in first system after vertical frame
Reported version
3.0
Priority
P1 - High
Type
Functional
Frequency
Many
Severity
S4 - Minor
Reproducibility
Always
Status
closed
Regression
No
Workaround
No
Project
When I edit a hairpin or any automation placements or add a vertical frame is systems, suddenly "long instruments name" appears!
And, When I increase or decrease the height of the vertical frame
and sometimes some symbols that are not in the corrected location must adjust again.
| Attachment | Size |
|---|---|
| Hummel - String Quartet No. 1 in C major, Op. 30.mscz | 92.82 KB |
Fix version
3.6.0
Comments
I can confirm the 1st issue, but it seems to be just a temopary glitch, vanishes not only after edditing the frame, but also on a save
Don't understand what the 2nd issue is about
Also what purpose serve these vertical frames? What purpose do they serve better then using a spacer instead?
Yes! I will replace a spacer for this score instead of the vertical frames.
But! this issue:
1. Add the vertical frame - The long name instruments appears.
2. Edit the vertical frame (increase or decrease the height of the vertical frame) - The long name instruments hidden.
3. Again!, edit the vertical frame (increase or decrease the height of the vertical frame) - The long name instruments appears.
And when I insert system break, the problem is the same.
To me it looks like the frames are being used for text that really belongs in the header. But indeed, it's a bug, easily reproducible, that the long instrument names temporarily appear on any edit on the first system after a frame.
In reply to To me it looks like the… by Marc Sabatella
The text is in the header already, the frame is (miss)used to create some space so the header can be seen.
Came up again in #313939: Odd short-to-long instrument naming behavior, especially when a vertical frame is present, along with sample files and some deeper analysis
This problem is not just caused by a vertical frame. I also found this "Instrument Name" fault on a score page with many spacers: removing the spacers seemed to cure the fault. See sample score here:
https://musescore.org/en/node/313906
My guess is any issue with spacers will turn out to be unrelated in terms of cause, even if the symptom is similar. But I'm still investigating.
Fixed in branch 3.x, commit d8fa6e6dea
_fix #288098, #307301, #305958, #295629: interactions between breaks and frames
Resolves: https://musescore.org/en/node/288098
Resolves: https://musescore.org/en/node/307301
Resolves: https://musescore.org/en/node/305958
Resolves: https://musescore.org/en/node/295629
A number of bugs all turn out to be related to a single root cause,
where we don't correctly handle checking for section breaks
in the presence of frames.
In the case of the long instrument name showing inappropriately,
it's because in the case where the previous systems is just a frame,
we don't see any measure,
so we fall back to relying on the layout of the previous system
having already set up the context for us.
This isn't necessarily valid when doing partial layout.
So we need to check more thoroughly here,
accepting a frame if it has a section break itself,
but otherwise searching backwards looking for frame with a break
or a measure.
That is, we need to skip break-less frames when looking to see
if we are starting a section.
I have therefore implemented such a function.
This turns out to also fix an issue with horizontal frames,
where a break on a horizontal frame ending a system
was being ignored for the purpose of setting long names.
The same applies to the new first system indent facility,
so while these bugs are not recent regressions,
they take on new importance in 3.6.
The new function is also used to fix a related by with measure numbers,
where a frame could get in the way of resetting them after a section break.
It is used again to solve the corresponding issue on MusicXML export.
Along the way I discovered a bug leading to an assertion failure
when deleting breaks attached to frames,
so I needed to fix that by making sure LayoutBreak::measure()
doesn't assume its parent is in fact an actual Measure
as opposed to a MeasureBase._
Automatically closed -- issue fixed for 2 weeks with no activity.