Horizontal spacing/stretch
(EDIT: See my last comment down below, with a much more detailed presentation of the problem and the solution, along with music examples that demonstrate the issue more clearly.)
I have followed the efforts from the new engraving and design team to get Musescore up to "industry standard" and produce professional looking scores out of the box with great excitement and high expectations.
But there is one issue that I have been missing in the discussions and presentations: horizontal spacing.
I am not thinking here of the micro-level issues regarding accidentals and cross-beams etc., but the overall way of laying out whatever music there is nicely on the assigned space of paper.
Of course, there may be cases where one would want the last system to be unfilled, but in music printing, even more than in text, the rule is that one wants to fill systems and pages and distribute the music as evenly as possible over whatever space is necessary at the moment: a full-width last system is better than a narrow one, and a full last page is better than one with a single system on it. If there is one thing that makes a score look unprofessional, it is when there are chunks of music with irregular spacing. Unfortunately, with Musescore, it is almost parodic how often a small change somewhere in a score results in one single measure on an additional system, perhaps even on a new page.
Currently there seems to be a limit set at three measures in Musescore: up to that point, the last system of a score will be left-aligned - add another measure, and the last line will be justified. This is presumably to avoid having a full-width measure. But the expected behaviour - i.e. the behaviour that would produce the most professional-looking score - would be to recalculate all the music up to that point, to find the best distribution of measures of the score as a whole, in order to achieve the ideal of full systems and pages.
One reply that one frequently meets in the forum when issues like this are brought up is that it is very easy to add manual system and page breaks. That may be so, but it is not a solution. It would be like telling a (digital) typographer to just add hard line-breaks at every line. That is of course not how it should work.
I see two different issues related to this:
What Stretch should do
- If the suggested behaviour requires too much constant calculation to be practical during note-input, the Stretch system should be improved, so that one could at least achieve professional-looking scores with a separate operation. It seems that "Reset stretch" currently does NOT recalculate the spacing of the piece as a whole, but only resets it to whatever it was (or would have been) before any manual changes.
The Lesson from LilyPond and LaTeX
- Following up on this, I've always (i.e. since before MS 1.0) wondered why there doesn't seem to have been any cooperation with the LilyPond community. If there is one area where Lilypond shines, it is in the field of horizontal spacing, where the LaTeX ideal of producing ideal defaults and good algorithms for dealing with standard situations is translated very successfully to music notation. In music, more than in text, it is necessary to do "paragraph" based and not line based calculations. Today, Musescore seems to do line by line (like Microsoft Word does): justifying one line of text/music, and then letting the next note/letter take care of itself. LaTeX instead evaluates the whole paragraph to get as evenly spaced text as possible. That is what Musescore should do too.
I welcome comments - and if what I'm after can already be done, then I'm all ears.
Comments
Format > Style > Page > Last system file threshold defines whether or not the last system is filling the page with or not.
In reply to Format > Style > Page > Last… by Jojo-Schmitz
Yes, but that does not take care of the general issue, it only lets one decide whether one wants an ugly page with one measure in the last line, or an ugly page with a full-width last line with one measure in it. My point is that that situation should not occur at all, other than in very simple situations, e.g. with very short pieces, since even music before the last line should be calculated to allow the whole score to be evenly and beautifully spaced.
In reply to Yes, but that does not take… by eyolf
I don't know if there are plans to take care of orphans though this would be a neat idea. I use hard system breaks in all of my scores so I don't leave orphans but not everyone does that. I think at times the measures get too crowded by default so in my original scores I don't let this happen. In scores I copy, the crowded measures allow the manual system breaks with less editing.
The algorithm for spacing in a measure is being totally rewritten from what I understand so the general spacing in a measure should be better out of the box.
In reply to I don't know if there are… by mike320
One thing I forgot to mention in my original post: there should be a preference - both a general setting and a per-score - to prefer dense, wide or neutral spacing. That would save you from all the hard breaks. (Maybe there is already something like that, but if so, it is well hidden in all the number boxes in the Style settings.)
And as I indicated: in text, orphans are ok - in a score, they are not-so OK. Musescore should handle that, and if that is underway, then we are getting a huge step closer to setting and not following the industry standard for typesetting.
In reply to One thing I forgot to… by eyolf
There's not a 3 way toggle for wide, dense and neutral spacing or even a one or two step system to easily switch between the 3. There is a lot of control over how notes and measures are laid out. You can play with all of the style settings until you have each of the three set in your opinion then save each of the 3 as a style in the menu Format->Save style. You can then load the appropriate style for the score you are working on and have this as a custom functionality. It will be a bit of work to set it up but could save a lot of time in the future.
As for the hard system breaks, I'll never stop using them. In my copies I need the systems to match the PDF, no matter how ugly they are. In my own scores I use this to spread out most measures and keep text from running off the margin.
In reply to There's not a 3 way toggle… by mike320
I would say that for my uses - writing music for people to play - practicality of layout is higher priority than appearance.
In my experience, laying out music on a page has to make compromises between several competing factors including readability, having easily recognised "signposts", minimisation of page turns, providing time for page turns. I try to follow the following rules:
In most cases it is not possible to follow all of these rules and some or many have to be broken or bent. Once the compromises have been made for these practical reasons, I can start tweaking horizontal and vertical spacing to improve the looks, but that is the easy bit.
I wonder how automatic layout algorithms can deal with the practical compromises that have to be made.
In reply to I would say that for my uses… by SteveBlower
Your rules are excellent, and also a good example of the dilemmas that will inevitably come up. They are also, incidentally, a great example of how the LaTeX model works: by assigning penalties to certain situations, and a good set of default values to these penalties. How do you for example find the balance between hyphenation and big gaps between words? You let a good typographer set a penalty, and override it when the results are not to your satisfaction. All of your rules would be penalized, so that unless weightier penalties apply, repeats would start and finish at the end of systems, etc.
The idea with a typesetting program that wants to be the best (and not just a decent, free alternative for those with low expectations) is to make good decisions for all those who don't have a degree in typesetting and musicology.
So the answer to your question is: they can actually deal with them very well. Not to the extent that no manual intervention is ever needed - they can not read minds, and your preferences may differ from mine - but they should minimize the need for manual intervention.
In reply to Your rules are excellent,… by eyolf
Interesting ideas. Would you see this as a post processing sort of thing - a big friendly "layout" button that you press after all the notation is entered? I would imagine doing this sort of thing on the fly could slow down notation entry to a crawl.
In reply to Interesting ideas. Would… by SteveBlower
I can imagine both - hence my two scenarios in the first post: one where the Stretch system is improved to work as a big frienly layout button, as you so aptly put it, and another where it is done on the fly. It may be that it will slow things down, but: (a) a compromise would be to do the recalculation only when linebreaks are involved. An example is what happens if you add a manual break in the middle of a line - now, you are left with a half-empty line where nothing at all happens with previous lines; or (b) we are talking ideal situations here, and computing power increases, code is optimized, so that today's slow operations may not affect the future, so to speak.
have you seen https://musescore.org/sites/musescore.org/files/2020-03/Improving%20Mus…?
In reply to have you seen https:/… by ecstrema
I hadn't seen the final document, so thanks a lot!
I followed the thread for a while, but I got away from it - too soon, it seems. But those are the micro-level spacing issues that I alluded to in my post. Turns out, they are not really micro-level issues but more closely related to the issues I bring up than I initially thought. But they are not completely related.
What the document makes very clear is that part of the problem with MuseScore spacing is that it has the measure as the basic unit. The highest level check that is done, concerns the number of measures that fit in a system, and all adjustments are made to the individual measures. But typographically speaking, the measure is the least interesting unit. What we want is consistent and beautiful spacing on the note-to-note level, but also on the page-level (so that all the systems on a page or a spread look evenly spaced) and score-level. What MuseScore does is precisely what MS Word does to paragraphs: calculate each line (=measure) separately, without concern for the paragraph (=system or page).
Barnie Snyman's solution comes closer to the ideal by downplaying the role of the measure in favour of the note-to-note level, thus relating the entire score to a common standard, but it still does not check the higher levels of page and score. Maybe that's enough, though. Time will tell.
But that brings me back to the second point in my original post: why not take advantage of the insights the LilyPond team have made? That is exactly the kind of calculations that whole project excels in. If the spacing algorithms from LP could be joined with the functionality of MS, we would really have the best music typesetting program in the world, and not just a free app with great flaws that "will prevent MuseScore from ever really being taken seriously outside the hobbyist/student-circle," as Snyman so aptly puts it in one of his posts ( https://musescore.org/en/node/299741#comment-972218 )
Fascinating thread! I've always used system breaks to manually fix the problems you describe. It never occurred to me that this could be automated.
If I understand your "Reset stretch" idea AKA "big friendly layout button" correctly, then the algorithm could possibly go something like this in broad terms...
1) We have this score with tight spacing except for the last three measures:
2) We want to even out the number of measure per system throughout the score. So we incrementally increase the entire score's stretch to force more measures into the last system until its spacing is more or less consistent with the rest of the score.
Increasing stretch to 1.05 gives us:
This is better, but the last system is still more loosely spaced than the rest. So increase stretch again up to 1.1 and we get:
Now spacing is more or less even right to the end.
Of course this method is probably as rudimentary as it gets, and plenty of other factors (like those mentioned by SteveBlower) could be brought into consideration.
This is definitely a nice item to add to the already very long engraving wish-list!
In reply to Fascinating thread! I've… by BarnieSnyman
Your example illustrates well the difference between the LaTeX approach to laying out paragraphs, and the Word model, which I've alluded to. Word (and Musescore) does this:
![Screenshot from 2020-11-15 10-27-00.png]( "Screenshot from 2020-11-15 10-27-00.png")
![Screenshot from 2020-11-15 10-30-34.png]( "Screenshot from 2020-11-15 10-30-34.png")
The first line is filled up with words, and when a word no longer fits, it is moved to the next line and the current line is stretched to fill the score width, exactly as MuseScore does. Whatever happens in the next line when it is filled up, the former line is forgotten, disregarded. The result in this case is a nice first line and a second line filled with holes - quite equivalent to your first example.
LaTeX does this:
The single line of text is an arbitrary unit; what matters is the inter-word space and the paragraph as a whole (equivalent to system breaks and the beginning and end of the piece), so the entire paragraph is taken into account when line breaks are made. In this case, the ugly holes in the second line would have given so much penalty that the layout would have been recalculated, and the version where "with" is moved to the second line would have given a more pleasing appearance overall. The second line is still not pretty, because of the long words (and no hyphenation) but since the extra space of that word can easily be distributed among the many short words in the first line, it is less obtrusive.
This is what the Big Friendly Layout Button in MuseScore should do: reset completely the whole "paragraph" and see: which distribution of "words" (measures) would give the most pleasing appearance of the paragraph. So what we want is not to even out the number of measures per system; we want a consistent look, and the way to achieve that is by moving measures around, since they are the smallest units (unless hyphenation is used).
The second problem with the current Stretch system is that it does not penalize ugly solutions. In your third example, the output is better than the original, but it is still not good: now the last line is more crowded than the first ones! It follows the Word model: fill up each line as much as possible given the current constraints (i.e. stretch level), and move on to the next line until each separate line has been treated.
![Screenshot from 2020-11-15 11-04-34.png]( "Screenshot from 2020-11-15 11-04-34.png")
And if you add another round of Stretch, chances are that you would end up with this instead:
Since there is no penalty for creating an ugly last line, the stretching process just continues until it goes too far, and one has to back up one step and be satisfied. Or just a little less dissatisfied.
This is not to say that I think everything can be solved algorithmically, but a system that is based on
would come a very long way towards achieving good results out of the box.
Comparison with LilyPond
I ran your example in LilyPond. This is what I got out of the box:
![Screenshot from 2020-11-15 11-18-34.png]( "Screenshot from 2020-11-15 11-18-34.png")
![Screenshot from 2020-11-15 11-18-21.png]( "Screenshot from 2020-11-15 11-18-21.png")
![Screenshot from 2020-11-15 11-25-17.png]( "Screenshot from 2020-11-15 11-25-17.png")
I.e. your third example. (so maybe the spacing of the last line isn't so bad there after all...)
The only way to achieve the "bad" spacing in your first example is to add manual breaks. And here's the final and quite revealing illustration of the shortcomings of the measure-based spacing algorithm: If I add a break after m.7 to get to your first example, this is what LilyPond does:
Whereas if I do the same to your corrected third example in MuseScore, I get this:
Lilypond recalculates and finds that m.7 does indeed fit in the first system - MuseScore is indifferent to that, since that system has already been processed.
Personally, when I get to the layout phase, I use { and } commands over hard system- and page-breaks--I find it more flexible; and I expect I would continue to use no matter what automated algorhythms are put into place. Repeats and else aside, I like phrases, entries, cadences etc. to fall in specific spots in the system. I doubt any algorhythm can understand the grammar of music to that extent.
I do find MuseScore's difficulty in adjusting horizontal stretch WITHIN a single measure (as you said, not micro-placement, but general density in a half measure, e.g.) to be a limitation.
Now, vertical placement . . . . (I can't wait!)