Measure Layout Stretch editing makes first notes to align incorrectly
When creating or editing a score to make a certain section fit into one page, it is common for me to use the measure layout stretch option found in the measure properties menu (right-clicking a measure) and set the stretch to 0.9. This can result in the measure being more compressed and the following measure can come up to the current line. While my copy of MuseScore 2.0 beta (running on 32-bit Windows 7) fulfills this task, it also causes the first note of the following measure (the measure that came up to the line you were working on) to "stick" to the barline.
For visual aids, I have attached a screenshot of what the notes in the measures looked like before using the layout stretch and after using the layout stretch. I have also attached the actual mscz file of the issue in question. Please refer to measures 6, 8, and 10. The problem may be reproducible for any measure.
| Attachment | Size |
|---|---|
| Before layout stretch.png | 50.62 KB |
| After layout stretch.png | 70.39 KB |
| Prélude_No._6_in_D_Minor.mscz | 15.6 KB |
Comments
I think this is just fact of trying to "stretch" too far. Those notes simply won't all fit given your other style settings (eg, space/scaling, minimum note distance). If you want those measures to fit on one line, you'll need to change some other setting too.
I am pretty sure that is all that is going here. For instance, setting style / general / measure / minimum note distance to 0.20 rather than 0.40 allows the notes to be placed closer together and thus the two measures fit.
Thank you for the information. However, it is worth noting that this problem never occurred in MuseScore 1.3 with the default settings regarding the minimum note distance; it automatically squeezed the notes inside the measures without overlapping with each other. I do not want this to prevent me from using MuseScore 2.0; I had reset the layout to match the new layout that 2.0 had and attempted to compress to 0.9 again, but the problem still persisted.
That's not really true. It might have worked for this particular score (was it originally created in 1.3?), but it was very easy with MuseScore to get it to show the exact same effect. If this is a score you original created in 1.3, try reducing stretch a few more notches to fit three measures on one system, and you'll probably see it fail int he same way, but more spectacularly.
So the only thing that probably changed is some default setting or other aspect of the layout algorithm thats this particular score to need a slightly smaller minimum note distance or other difference in order to fit compared to 1.3. There are a ton of layout improvements - major improvements, see http://musescore.org/en/node/25102 - in 2.0 Beta 1, but the end result of this is, some things do now (correctly) take slightly more space than in 1.3, so it might occasionally be necessary to reduce some setting in order to get something to fit that used to fit by default.
Feel free to upload the 1.3 version and I could look to see I can find the source of the difference, but it won't really matter - unless there is a bug here (which I kind of doubt), you'll just have to reduce a setting for this particular score a little.
This score was actually downloaded from musescore.com; I am using it to help myself practice this piece and I was just fiddling around with the score. As a result, I do not know what version of MuseScore the uploader used (most likely 1.3).
I have attached the original file that was on musescore.com.
This was interesting to see, thanks for bringing it up! It appears the difference in this case is the ledger lines. These are what are causing the measures to not fit in 2.0 whereas they do in 1.3 - 2.0 allocates slightly more space for the ledger lines than 1.3 did. For one thing, the ledger lines themselves are a little longer by default. But also, I suspect that in 1.3, the ledger lines were ignored when applying the "minimum note distance parameter" - this was treated as the minimum distance between note heads, to the point where ledger lines might overlap if the minimum distance was set too low. Whereas in 2.0, for notes with ledger lines, this seems to be the minimum distance between the ledger lines, so the lines never overlap no matter how low you set the minimum distance.
I think I'd consider the 2.0 behavior more correct than 1.3 - both in terms of default ledger line length and in treatment of the minimum distance parameter. So this is indeed just one of those cases where the improvements to layout mean things take slightly more room than before by default, and reducing one or both of those two parameters would be necessary in order to fit those measures on one line.