behavior of hairpins (and lines in general) through hboxes (and through system headers)
Minor issue here. If I start with these measures with HBoxes (aka "horizontal frames") inbetween like this:
(note, I've disabled "show clefs on all systems" so 2nd line doesn't have clefs)
and then I add a single hairpin through all four measures like this:
On 2.0.2 and nightly 4dbec86 I observe this behavior:
- hairpins restart their vertical thickness after each hbox
- hairpins will display through the hboxes
- hairpins don't display through system headers (header clefs as well as keysigs)
- if hbox followed by measure without system header, then there is a discontinuity in the hairpin thickness
Note that all lines have similar behavior when going though system headers and hboxes, so I think this post goes for all lines.
I think it would be consistent for lines to behave in either of the following two manners:
- not display through hboxes & not display through clefs
- both display through hboxes & display through clefs
Instead of displaying through one and not the other.
I also think that if it is intended for lines to display through hboxes, then there shouldn't be a discontinuity in the hairpin thickness. According to object debugger, each of those measures constitute an entire system. I understand that the reason for having the thickness reset on new systems is that it is desired to do so when laying out a new system on a new line.
It seems the hboxes always force a new system to be laid out after. So I think the best way to be consistent is to simply not have lines display through hboxes, then hairpins won't have the discontinuity in the hairpin thickness. Also musicial notes don't occur on hboxes, so I think it makes more musicial sense to not have lines go through hboxes by default. (anyway, user can always manually extend the ending offset so it could go through hbox if desired).
| Attachment | Size |
|---|---|
| hairpins-over-hboxes.mscx | 4.81 KB |
Comments
As you may have realzied by now, hboxes actually create multiple "systems" on a single "system row". The line layout code probably doesn't understand this, and creates a separate line segment for each system when it should really only do so for each system row. This might not be trivial to change; the "system row" abstraction is not particularly well-exposed.
In reply to As you may have realzied by by Marc Sabatella
OK, I can accept that if it is not trivial fix, then is probably not worth the time.
In reply to OK, I can accept that if it by ericfontainejazz
Well, I said it *might* not be. It's certainly worth a look, but my gut says it won't be simple, too much in the code depends on systems only, not system rows.
In reply to Well, I said it *might* not by Marc Sabatella
question: is it even desired to have a new system header after hboxes?
In reply to question: is it even desired by ericfontainejazz
Sometimes yes, sometimes no. Depends on your reasons for the hbox.
In reply to Sometimes yes, sometimes no. by Marc Sabatella
I've though about it a lot, and I think that the semantics of hbox should mean nothing more than there is a horizontal frame. So I don't think a hbox should trigger a new system by default.
I think there could be a boolean Measure property "forceTriggerSystem" which user could select via inspector which would force a layout of system header starting on a measure. Or could work with all measureBase obejcts in which it would be called "forceTriggerSystemOnNextMeasure". I'd say default should be set to false, which would not interfere with the rest of logic responsible for laying out a new system (e.g. VBoxes and SystemBreaks would still force layout a new system because their next MeasureBase object would be on a new line). But adding a property to datastructure & fileformat might not be popular.
Regarding reasons for hbox, I think composer may have different reasons, hence why I think better to have the force layout of new system be a separate issue. One reason for HBoxes I find I need quite often is that I want to make some comments about soloing which might not fit cleanly as staff text, so I might put a repeat sign and then add a text HBox after, in which case afterwards I don't necessarily want a new system header. a Or I might have a note with fermata which is followed by a very percuilar cue that I want to write after the fermatin a HBox instead of as staff text, and then afterwards I may or may not want a new system header.
I've identified the blocks of code in Score::layoutSystem() and Score::layoutSystem1() which is responsible for creating a new system after the HBox, and after removing them (diff here: https://github.com/musescore/MuseScore/compare/master...ericfont:78566-…), the hairpins then have a continuous thickness change through the hbox, which I find acceptable:
![hairpin-through-hbox-after-remove-forcing-new-section.png]()
But then if I add a begin repeat, keychange, and clef to meas 1, I notice there are issues with begin repeat signs not showing up at the *beginning* of the measure:
![hairpin-through-hbox-after-remove-forcing-new-section-with-clefs-and-repeats.png]()
(There is also the question of that clef which if I add to meas 2 actually shows up on meas 1 before the repeat sign, but I understand clefs are complex issue and I think that there should probably be a seperate feature request to not have clefs inserted at start of measure to not appear before end repeat barlines.) (And there is no start barline, but again, I think that if add a boolean property to measure to force new system layout at that measure, then user could instead enable the show barlines at start of new system and disable show clef/key change on all systems.)
Now if the reason that block was coded was to allow for start repeats & start barlines to appear after the hbox, then I can understand that, but I think it would be better to instead to have logic to make repeat barline start at beginning of measure after HBox instead of always creating a new system.
In reply to I've though about it a lot, by ericfontainejazz
Just curious what your real world use case is here. The one I know of really would normally call for a new system header, so as default behavior, it makes sense to me. But an option for disable it wouldn't bother me.
In reply to Just curious what your real by Marc Sabatella
My use case 1: I'm in orchestra rehearsal, and a simple text message after a fermata would have saved rehearsal time:
![use-case-text-after-fermata.png]( "use-case-text-after-fermata.png")
sometimes that fermata or other elements like chord names or bemas get in the way of where I would put such system text and sometimes it is hard to make a long text string fit in a measure while ensure it is still readable on all auto-generated parts. And I want to put the text in the most appropriate spot, which is after the fermata & before the next measure in this example.
Use case 2 which I find myself needing when there is some a fair amount of notes needed to make about how to repeat form for solos and how to know when last solo finishes:
![use-case-text-after-solos.png]( "use-case-text-after-solos.png")
and after that note I might want a begin repeat sign, but not a full system header.
In reply to My use case 1: I'm in by ericfontainejazz
No doubt such special case situations exist, although I'm curious to see actual examples from published music. I can't *ever* recall seeing a horizontal disconuity used in the way you show. If you need more room for text, the normal thing is to open up specae *vertically*. I can't think of a single time I've ever seen it done as you show.
Anyhow, no doubt there might exsait somewhere an example or two of this in the published literature. But the cases where you want the header surely *far* outnumber these. Basically, after any sort of *musical* discontinuity - if the two measures don't literally follow each otehr directly - it is normal / proper to incldue a full system header. And if two measures *do* follow each other directly, it is almost unheard of to separate them visually.
In reply to No doubt such special case by Marc Sabatella
I understand no need to handle every fringe use case. I admittedly can't find a published example quickly at the moment (although I'm not sure there are many examples of HBox in middle of a line, either). I will accept the argument that for any musical discontinuity that it is normal/proper to include a full system header. So I won't argue further.
(But just for the record, here is another potential use case: There is a short cadenza or burst of free improv after a fermata which composer doesn't want to exactly notate and so includes a small picuture with squiggely lines, but wants regular notation to resume at next measure, so inserts HBox with picture.)
The reason I started this thread was because I was investigating https://musescore.org/en/node/78331 and was considering one resolution to be not start new systems after HBoxes. But thanks for your time answering me...I know I better instead look into alternative solutions to that issue.
In reply to I understand no need to by ericfontainejazz
And for the record, I'm all in favor of an *option* to control whether that header appears or not, for the isolated cases where you might not want it. But I actually suspect that if you do succeed in finding published examples where there is a visual discontuity even for the types reasons you cite, a good amount of the time, the system header *will* be present. I am not thinking msot people would use this option often, but it would be good to have.
I would also suggest that even in the cases you cite, it's as likely as not you'd want the line to break. So ideally, these would be independent options: start new header, and break line. But in practice, having a system header but not breaking the line would be very difficult to implement: headers occur only on new systems, but new systems break lines.
So I think a reasonable compromise would be, keep the current behavior where hboxes start a new system, but add an option somewhere (right click menu on hbox, or on the subsequent measure, or on the header elements themsevles) to control whether the header elements display.
In reply to And for the record, I'm all by Marc Sabatella
Good points.
I'll add to the issue tracker a feature request for "option to disable new system after a HBox" with description similar to what you said here:
And I'll ask for any seconds to see if any interest.