Crescendo signs keep moving in score
Hi,
I am using 2.0.3 and notice a behaviour I have not seen in 2.0.2 before. I am editting a large score and I am 100% I have placed crescendo's in specific bars. However somehow the signs are moving in the score.
I think it is caused by the fact to score is keeps re-paging because more notes get entered.
This is pretty annoying, it is even annoying for me to consider to downgrade to 2.0.2 as it did not happen in that version. However before doing so, I thought it would be better to report the issue.
The problem can be seen in bars 104-108. Crescendos should appear in bar 106 and 107 but currently appear in bar 105, 108. When you double click the crescendo you can also see their anchor point is bar 106 and 107.
I am editting in Page View and have pages horizontal placed.
Hope this can be looked into and even better resolved as it is not nice that I keep need to correct this and what is even more annoying if this happens to crescendos, does it happen to signs others as well?
My best guess is that the re-paging is sometimes causing the crescendo to be split over two pages (even though they are just covering 1 bar and as such a split should not occur).
If you know any tricks that I can use to avoid this, please let me know.
| Attachment | Size |
|---|---|
| Mexican Shuffle.mscz | 43.87 KB |
Comments
They look like having been dragges around. Select one, right click, select all similar, Ctrl+R
In reply to They look like having been by Jojo-Schmitz
I did not drag them myself, it was done "by MuseScore" while I was just editting (adding a part).
I have removed the signs now and added them again (the third time). Ctrl+R won't work for me as this will reset all and I have to adjust the position again (get them as close as possible to the staff line without overwriting the notes).
I'll try to keep an eye on them to see if I can find when they get moved.
In reply to I did not drag them myself, by Henk De Groot
FWIW, you shouldn't really do that. Haiurpins should be in a fixed horizontal position, same as dynamics, except when a note below the staff causes a collision so you need to move the hairpins to avoid it. There are other special-case exceptions, but the general rule is that you should strive for consistency of placement.
In reply to FWIW, you shouldn't really do by Marc Sabatella
I do need to move them, as otherwise they will be too close to the staff below. But in general I almost move them all up (to get closer to the staff) with the same amount when there are no collisions with the notes. Same for the dynamics as well.
In reply to I do need to move them, as by Henk De Groot
Probably better to use the settings in the Hairpins, Volta, Ottava section of the General Style dialog, and correspondingly change the Dynamics' text style.
FWIW, there were similar reports from one or two users for 2.02, but no one has ever been able to pin down a a specific way to reproduce the problem, so we haven't been able to identify and fix the problem. Meaning, it seems pretty obscure and almost random, and going back to 2.0.2 probably won't change anything - whatever the problem is clearly there as well, even if neither of use have run into it.
See for instance https://musescore.org/en/node/88321
Looking at your score, really, many of the hairpins have fairly large offsets applied to them. Are you *sure* you did not move any of them manually? For example, the hairpin in measure 79 has been move 7sp, the one in measure 81 has been moved 18sp. These two are *also* preceded by cresc/dim lines, making me wonder if maybe you originally entered hairpins, then moved them off the page for whatever reason and forgot they were even still there, then entered new cresc/dim lines to take their place. And then some shifting around has caused those hairpins, previously moved off the page, to now appear on the page again. At least, that's what it *looks* like has happened. So even if this isn't what actually happened, it might provide some sort of clue into figuring out steps to reproduce this.
In reply to FWIW, there were similar by Marc Sabatella
Hi, I am really sure I did not move them myself. I normally enter part by part. Once I fully completed 1 part, I start with the next and don't update the other any more.
Because 2.0.3 now has dim/cresc lines in it, I am using this. The reason why both the text and the hairpin is there is because that is how it is in the original parts. Before 2.0.3 I would have used stafftext. Maybe it is better to use that anyway.
I have entered 2 more parts now and no changes seen in the hairpin positions, these parts did not do any re-paging as these are very similar to other parts that have been entered already so no changes in the width of the measures.
EDIT: I now see this "problem" does seem to appear when I open the score. Yesterday when I stopped working, I had corrected all hairpins and none of them were out of place. Today when I open the score again, they have been moved. See screenshots. This only seems to happen when I have re-positioned some of the hairpins. When I do a CTRL+R on all of them and then re-open the score they seem to remain in position. Any thoughts how I can provide a score to you before it is saved???
In reply to Hi, I am really sure I did by Henk De Groot
I have found 1 way to reproduce the movement of the hairpins. All these actions done in page view with pages horizontally placed.
In the attached score I selected a hairpin, selected all similar and pressed CTRL+R.
Next I saved the score.
When I open this score again, all still looks fine.
Now follow these steps to see the problem:
- Go to measure 79/80 in the 1st Bariton part
- Double click the hairpin
- Select the middle handle
- Press CTRL + up-Arrow
Now a re-paging of the score takes place, measure 80 is moved to the next page (15) and there are 20 pages in total.
- Press ESC
- Save the score
- Close the score
- Reopen the score
At this moment the previous 20 pages have changed back to 19 pages. Measure 80 is back on the same page (14) it was before changing the hairpin. However the hairpin is placed into measure 80 and next to this measure (where there is no staff).
In reply to I have found 1 way to by Henk De Groot
Brilliant!!!! Yes, I can now reproduce the problem!
So far, while two or three people have reported seeing this happen, no one has been able to figure out the exact series of steps that lead to this behavior, so we haven't been able to do anything about it. Armed with this reproducible series of steps, hoepfully we'll finally be able to tackle it.
Thanks for your investigation! Can you file this as an official bug report in the issue tracker?
I'll reiterate what I said before, FWIW - this bug has been around since 2.0 (at least) but it only shows up in very particular situations that seem to be rare / hard to trigger. Probably the reason you didn't see it with this score in 2.0.2 is that the layout was just different enough that no shift happened while adjsuting the hairpin.
Actually, it's a bug that the shift occurs at all, and it isn't just the hairpin adjustment that triggers it - anything that forces a layout will cause the shift. Even just Ctrl+A. The cases I've seen in the past where Ctrl+A would force a relayout mostly had to do with calculation of sizes for courtesy key signatures or other elements that would appear and disappear depending on where the break happened. I suspect this case will turn out to be a simple floating point round-off different, since there really isn't anything in particular going on here that would obviously explain why the discrepancy might occur. But more investigation will be needed. And unfortunately, the layout is totally different in the current development version, so if I run under the debugger, I can't reproduce at all.
In reply to Brilliant!!!! Yes, I can now by Marc Sabatella
Created a bug report in the Issue Tracker: https://musescore.org/en/node/109021