Line Break Properties
I have been thinking about a number of issues relating to page layout and user control, and I have an idea for a relatively simple change that I think would be quite helpful. Looking for feedback before I think about trying to implement any of this.
Basically, I am proposing we add properties to the existing line break element (perhaps exposing this in the UI as a new type of break) to allow a line break to accomplish a few additional things that currently require other more awkward methods. They mostly involve wanting finer control over certain behaviors on a "per system" basis, but of course, systems come and go and on the fly so it's hard to pin down exactly how you'd specify something as working on a given system. So the idea of specifying this in conjunction with the line break that ends the system seemed like a decent way of leveraging something we already have,.
Here are some of the things I could see being controlled on a per-system basis using properties on the line break.
1) A "don't fill" property that would suppress the normal fill-to-right-margin you get on all systems but the last. Currently, you can accomplish this using horizontal frame, although it's kind of awkward - you actually need to delete the break first, then insert the frame before the next measure, then add the frame back. Although I'd also propose allowing "insert horizontal frame" to work with a line break selected.
2) Explicit controls over whether to hide empty staves in this system or not. Right now that's a global function only. If you want to have different behavior for different systems, you need to set it globally but then manually add invisible notes to measures on the systems where you want to suppress it. We could also consider adding a new element type that could be attached to a particular measure on a particular staff saying "I'm not empty".
3) A "Fit measures" property that basically says, regardless of current spacing, force the preceding measures (everything back to the end of previous system) to fit. Right now line breaks allow you to force *fewer* measures per line than the default, but the only way to force *more* is to manually reduce stretch. A common point of confusion. With this property, if you wanted eight measures to fit on a line but currently only six do, you'd add a line break after the eighth measure (which would currently be on the next system), set the "fit" property, and measures 7-8 would jump back to the previous system. Internally, we could basically pretend each measure had its stretch set to 1% of what it was really set to (thus scaling things so you can still stretch measures relatively to each other).
4) A property to force this line break to be linked to parts? Not so sure about this one, I still want a more general solution to the issue of controlling links.
5) Maybe make the line break draggable, as a quick-and-dirty way of adjusting spacing? Internally, we could make dragging the line break automatically add a spacer and put it into edit mode.
Implementation-wise, 1) would be trivial. The trick with both 2) and 3) would be that right now, we collect measures onto a system until we think it is full, and that could happen before we encounter a line break. But with my change, we'd want to keep looking until we see the line break, otherwise we won't know if we need to hide empty staves or not nor would we know if we need to fit measures. So the whole collect-measures-into-systems code would need tweaking. Shouldn't be *too* bad, but this code has actually been quite error prone in the past, and I know this has changed significantly in master.
For 3), we would also need to look at the stretch code to do something reasonable if you've asked for more measures on the line than we have any hope of fitting just by reducing stretch. As long we we don't crash, I actually don't care what ugliness results, though.
Comments
For 1) You could line breaks properties in the inspector. One of which is along the lines of make a hard line break, that is do not stretch the measures to the end of the line.
for 2) Perhaps you could include a measure property that says "Never hide this measure." With the work on making an inspector version of all elements, this should be rather easy and could be applied to several consecutive staves (i.e. all of the strings in a normal score) if the user desires.
For 3) To squish the measures asked for by the user, once the measure gets all of the stretched removed, perhaps you could make the measures small. I know this isn't the most desirable effect for someone looking to make a nice looking score, but squishing the measures to the point it is difficult to tell where one note ends and the next begins is just as ugly. Once the measure is shrunk, you could put a fractional or negative stretch on it to make it fit. Also, there is already leading space built into chords that could be manipulated by the layout algorithm.
for 4) since we know that page breaks are almost never common between a score and a part, perhaps allowing for an "Apply to all parts" option would be the way of putting common page and line breaks into all parts.
5) I think dragging line and page breaks like you do dynamics would be a good idea. This is actually something I would use. Just to clarify, if you drag a dynamic, the red line points to the note it is connected to. Make a red line for line and page breaks point to the end of the measure it will be applied to. You could even do this for section breaks for unity of operation, even though it would be used far less.
I'll add a request for 6) A reverse spacer would be a nice addition to this, so you can move lines closer together to accommodate putting an extra line or 2 on the page. I would use it most on the first page of a score that has all of the instruments, but only some have music on that page. 2) would help with this, so one could hide all but 1 flute line on page 1 if there are multiple lines and the flute has no notes on page 1 for example.
I'm not likely to use most of these, but it is a feature that has often been requested and I'm glad to see you considering it.
In reply to For 1) You could line breaks by mike320
As far as I know, the "reverse spacer" is already implemented for master. I actually did an implementation myself before the big "smart" layout changes, but I think maybe Werner re-implemented it.
For 2), I did think abotu a measure property to not hide a measure, but a complication is that right now most measure properties are global - applying to all staves at once. The only thing we expose as a per-staff measure property is visibility. But actually, since hiding is similar in principle, maybe we could add it there. Worth thinking about further for sure.
For 3), do you mean actually going with a smaller staff size? I guess that's possible. For that matter, that could actually be another explicit line break property - the ability to set a specific scaling factor for that system.
For 4), yes, an apply to all parts is a possible way to go. I've also thought about such a command to copy other manual adjustments to from score to parts. Right now by default we don't copy most manual adjustments on the assumption that often you want to maintain them separately, but there are no doubt cases where it *does* make sense to apply certain adjustments to both. I could imagine a command that would operate on a selection, going through all elements in the selection and applying their manual adjustments to all linked staves/scores. This wouldn't require any architectural changes at all and in fact could be done without introducing any incompatibilities at all.
In reply to As far as I know, the by Marc Sabatella
2) Yes, perhaps a check box for never hide next to invisible and stemless would work. That way it would affect only selected staves.
3) Yes, the small staff size you get when you check the box in the staff properties. It would have to be applied to a system I would think. A scaling factor for a system would be even better. I like more control for the user.
6) Since I only read about 3.0 in forums to this point, I'm not aware of many changes that have been made. I mostly learn about new features when people report bugs in them or someone mentions them to other users. I hope Werner did include it in 3.0.