Hairpins go on a hike

• Nov 26, 2016 - 03:45

This is an issue that keeps occurring to me, but which I can't describe with adequate precision to file a bug report or feature request. I am working with 2.0.3. and MacOS Yosemite.

This usually only happens in large scores (say a 10 minute string quartet movement or an orchestral score). After repeated work on a score (1. typeset, 2. proofread and correct, 3. format, 4. generate parts, the format parts for page turns etc., all the while correcting errors one missed on the first proofread). I find hairpins that have moved horizontally away from their anchors, mostly but not always forward. Not all hairpins in a score move and not all of those that do move move the same distance. Sometimes it is obvious that a hairpin is in a nonsensical location, but often it isn't. The only way to be sure to catch all hairpins that have moved is to double click each of them and have a look at the anchor lines (correcting this is obviously easy). I remember instances with other line elements like Pedal (piano) but I am not sure if these occurred with the present version of MS.

Here are two hairpins at the same place, moved one forward the other backward (BTW: MS's built in screen shot facility does not allow to take this picture, you'd have to unselect the hairpins to take a--useless--picture): hairpin 1.png hairpin2.png

As I said I know this occurs in large scores that have been worked on for a lot of time (which includes numerous save/load cycles), but I have no observations of details that would be connected to this behavior. So I am just asking some questions to the community:
- Has anybody encountered this behavior?
- Any observations about when this occurs, what triggers it?
- Has anybody got far enough to find a way to prevent it? Or can tell me where I am going wrong and cause it myself?

This is obviously a labor intensive problem as one needs to check on and correct every hairpin before printing.


I am using MuseScore 2.0.3 revision 3c7a69d on Windows 7 Pro SP 1

Has anybody encountered this behavior?
Yes, it was widely discussed here:

Any observations about when this occurs, what triggers it?
I could never give steps to reproduce the fault, and could only guess that it might be involved with changes of layout when switching between Page View and Continuous View. The link above does provide a lot of detail about the cause.

Has anybody got far enough to find a way to prevent it?
A bug report has been raised already (but not yet fixed):

Have you try with the INSPECTOR, after selecting all the similars elements in your work, to use, in the HORIZONTAL MOVING, to use the arrow completly on the right, this arrow moves the element on his original place. arrow.png

Thanks everybody! This fishing expedition was more successful than I had hoped. I'll try your recommendation and will report back in this thread. But it will take some time before I know if it works for me.

Do you still have an unanswered question? Please log in first to post your question.