Trills visually change location and/or note hangs after it's finished

• Mar 11, 2017 - 02:05


I have to say I love this app, it is simply great, even though there are some problems.
When I am making a score with a lot of instruments, trills (from the line menu) will move visually, but play as they should. This is a major problem for me, because when I fix it, save and start the application again, it is all messed up. This also applies for single parts, which is not great when I want to print singles.
In addition, crescendos and/or decrescendos tend to move near the thrills.
Trill ss.png
2ndTrill ss.png

In addition, I tried using the "tr" symbol (from articulations and ornaments menu) and this results in one or more notes playing for approx. a whole measure too long, ruining that part of the score (audibly).
3rd trill ss.png

The screenshots have a marked area, which are either where the thrill line should have been, or where the "extra" note plays.

Are there any workarounds to these problems, or are there simply nothing I can do before it is fixed?

Attachment Size
Trill ss.png 187.81 KB
2ndTrill ss.png 167.5 KB
3rd trill ss.png 155.61 KB


In order to investigate, we'd need the actual score - not just pictures - and precise steps to reproduce the problem. I'm guessing it will turn out to be the case that you have a system that is right on the edge of either fitting another measure or not, and MuseScore is having trouble deciding on that and this is throwing off the calculations. It's not a common problem, but one a small handful of people have reported. Again, though, we'd need the actual score to say for sure if this is what is happening, or if it is something else.

The playback issues looks like another one that is known - trills on tied notes play too long. It's something we are aware of but do not yet have a fix for.

In reply to by Marc Sabatella
Here is the link for the score.
Additionally, I found out that ONLY the crescendos and trills bug if they have been moved visually up/down/sideways in the score (to avoid overlapping the notes).

The problem can be reproduced by simply removing the trills, and adding them to the start where they are supposed to be.
Example: All flutes (4) from measure 38, 2nd beat to measure 40 beat 1.
Saving, exiting and starting should move the thrills further to the right.

In reply to by Kiffern III

Yes, this seems to be exactly the issue I mentioned before. Notice how when you first load the score, measure 34 is one page 4, but as soon as you do *anything*, it jumps to page 5? This is one of those cases MuseScore is having trouble deciding if that measure fits or not, and this in turn is causing it to get confused about your manual adjustments - whether they are relative to the way things look with measure 34 on page 4, or whether they are relative to the way things look with measure 34 on page 5.

We don't totally understand why this happens or how best to fix it, but the workaround is to add an explicit line break on measure 33 so that measure 34 is forced to page 5 and doesn't keep bouncing back to page 4. Do the same for measure 43, because the same thing happens there. Not sure exactly why, maybe something about measure 34 itself is confusing the calculations. We will need to look into this further.

Of course, you should only do this when you are basically done doing any major edits to what came before that point. Or be prepared to re-look at this later if the line breaks you insert end up not making sense.

This isn't something that comes up often, so unfortunately we haven't been able to figure this out completely and solve it, but we are at least getting to understand the issue better and see how to work around it.

For more information, see #109021: Hairpin and other symbols are shifting when relayout occurs

In reply to by Kiffern III

"The problem can be reproduced by simply removing the trills, and adding them to the start where they are supposed to be.
Example: All flutes (4) from measure 38, 2nd beat to measure 40 beat 1.
Saving, exiting and starting should move the thrills further to the right."

"Notice how when you first load the score, measure 34 is one page 4, but as soon as you do *anything*, it jumps to page 5?"

I don't see this here (2.0.3/Windows7) for now. Don't know why. Steps are not sufficiently detailed to reproduce or I miss something.
I see other thing, eg by deleting the page break in measure 26 (EDIT: measure 25)

Is it only the fact to do a minor change with the scaling (eg 0.940 instead of 0.950) in Layout -> Page settings, solves the problem for you?

In reply to by cadiz1

Well, I'm guessing the root cause of the issue is that when calculating the width of measure 34, we get some value like 5.9999999 units and we have room for 6, so depending on exactly how your computer hardware chooses to round that, it either fits or doesn't. Which is to say, the same thing that might explain why this happens in the first place might also explain why it doesn't happen for everyone - your hardware might always round it down.

Or maybe I'm wrong, but for me, it really is that simple - on first load, measure 34 is on page 4, but any action whatsoever (including simply press Ctrl+A) moves it to page 5. Are you saying when you load it, measure 34 is *already* on page 5, or that it is on page 4 and stays on 34 even if you make an edit to the score (or just press Ctrl+A)?

Another possibility is that whatever is going on here to cause the width of the measure to be difficult to pin down happens only on load. That is once the score is fully loaded, we have all the information we need, but maybe while initially reading it somehow we are missing some piece of info that causes us to underestimate the width of the measure. It's still rather mysterious to me.

In reply to by Kiffern III

Well, more and more mysterious.
By doing this: "on first load, measure 34 is on page 4, but any action whatsoever (including simply press Ctrl+A) moves it to page 5" , I don't see that. Nothing particular in the behaviour here.
While with the score attaching for this issue: #109021: Hairpin and other symbols are shifting when relayout occurs, ie Mexican Shuffle - Crescendo Reset to default_0_0.mscz, I observe an obvious layout change (new page added) with Ctrl + A

EDIT: which are your OS? (and with 2.0.3, I suppose?)

"This isn't something that comes up often, so unfortunately we haven't been able to figure this out completely and solve it..."

Sorry Marc, but this is a persistent problem. In my case it's affecting so much of my work with MuseScore, not least when I try to import MusicXML files from Sibelius. It's the most irritating feature of MuseScore, which in almost every other respect is a brilliant application which I absolutely rely on.

I have read the other threads about this topic, and I do understand that I can mitigate the problem by forcing a fixed layout with line breaks. But that is really just a workaround for a fundamental problem, isn't it? This problem seems to affect trills, hairpins and pedal marks, so it's wide-ranging.

In reply to by DanielR

I understand it is persistent on the scores that it afflicts, but these are only a tiny percentage of all scores. Really, if it affected *all* trills, hairpins, and pedal marks, we'd have sorted this out long ago. It's the fact that it only affects a small number of scores, and until fairly recently we couldn't find a way to reproduce it at all, that has so far confounded efforts to fix it.

However, I might have good news. As it happens I was just working on the part of the code that controls deciding how many measures can fit on a system, and since that appears to be part of the trigger here - a case where a measure appears on one system on initial load but then migrates to the next system immediately afterwards - I took a closer at this. And I *might* be clsoer to understanding what is actually going on here. But I could use some help from people who see the problem in their own scores to test a theory for me.

What I *think* is happening is that when initially loading a score, we are underestimating the width of measures containing repeat barlines. As a result, if we are close to being able to fit some measure on a line but really shouldn't be able to, we sometimes try to fit the measure anyhow. As soon as you do absolutely anything to do the score, we realize the error and calculate the correct width for the measures with repeat barlines, but by then its too late - we've already used the layout based on the incorrect measure widths as the basis for dealing with manual adjustments on lines on the affected pages.

If I'm right about this, the following should be true of scores that exhibit this problem:

1) the problem only affects lines that were manually adjusted

2) the score contains repeat barlines somewhere on or before the page where the problem starts occuring

3) if you watch the page containing the repeat barlines on first load and then after doing Ctrl+A, you should see the last measure move to the next page

4) if you delete the repeat barlines the measure moves back

5) if you then re-adjust the lines, save, and reload, the problem should go away

Let me know if I'm right about this, because if so, it should be fixable.

In reply to by Marc Sabatella


I have just re-imported a MusicXML file originating from Sibelius, but I can't reproduce the problem. I went through this sequence of tests:
1. Import the MusicXML file.
2. Select all the line breaks and delete them. Save the file.
3. Switch from page view to continuous view, move a hairpin vertically. Save the file.
4. Switch back to page view, insert line breaks in a couple of pages to push the last measure of each system onto the next system. Save the file.
5. The hairpins maintain their precise position in spite of all this, so I have to accept your view that this affects only a small percentage of scores.

And by the way, there were no repeat barlines in this piece. Most of my problems don't seem to be connected with repeat barlines i.e. there usually aren't any repeats in the affected works.

So sorry not to be able to produce a repeatable case at short notice.


In reply to by DanielR

Hmm, well, good to know that it might not *just* be about repeat barlines. But I still suspect it will turn out to be *something* causing a discrepancy in measure / system width calculations between the save and the load and the next layout after that. So more sample scores with reproducible cases will definitely help.

Note continuous view is *not* involved with this particular aspect of the issue. I can easily believe there might be *other* similar-looking issues that crop up if you try doing manual adjustments to lines while in Continuous view. Although I also suspect that some of those cases seen in the past may have already been fixed in 2.0.3 (or 2.0.2?), because we changed how save while in continuous view works.

In reply to by Marc Sabatella

Update: I have confirmed that for the two scores where I have been able to reproduce the problem, the issue is the calculation of the width of the repeat barlines, and I think I have found a fix.

I don't doubt there may be other cases that *don't* involve repeat barlines, so my fix won't apply. We could still use good reproducible examples. Other likely triggers would include courtesy key or time signatures or clef - they are also elements we might conceivably measure wrong at first and catch the error only too late.

In reply to by Marc Sabatella

My fix is merged. Meanwhile, I've been proactive and identified another case where this can happen that *doesn't* involve repeats. Instead, it involves courtesy key signatures, and the double barlines that get generated before them if there wasn't *already* a double bar before the new key signature. We aren't accounting for that correctly either, leading to the same basic situation. See #180991: Layout jump due to bad cautionaryWidth() calculation.

This one should be fixable too, although it's slightly more involved. Still just a few lines of code localized to one function, so hopefully doable.

The issue would only affect scores that contained a key signature change *without* an explicit double bar before it. Adding the double bar is considered good practice anyhow, so as workarounds go, this one shouldn't be too objectionable.

In my experience this problem is not as rare as Marc hopefully suggests though it is true that it doesn't afflict every score. But if your score is a bit on the big side, especially orchestral scores, you have a good chance to encounter it. This seems to point to Marc's explanation though: The longer the score the higher the probability of such a flip flop measure somewhere.
I have seen it happen with hairpins, voltas, trill lines and pedal lines.

I wanted to add that the fastest and most reliable way to fix this is: Right click an item that has moved, select all similar items (you have to do this for trills, voltas and hairpins separately) and hit the reset button in the inspector (horizontal offset; the U-turn arrow to the very right of it).

This is very fast and will fix the positioning on all items that have moved (I believe you need to do this in continuous mode in case some item has wandered off the page altogether). Unlike for trills and voltas it is not always obvious that a hairpin has moved, so correcting them by hand almost inevitably leaves you with incorrect items still in the score.

Before printing or exporting to Pdf I always do this, then go over the sore one last time to correct the last graphic problems, then I immediately export to Pdf where of course nothing will ever move anywhere.

If Marc is right all this will go away once we have version 3.

In reply to by azumbrunn

Well, I can say I've created literally hundreds of scores and never seen it once, and of the (tens/hundreds of?) thousands of people using MuseScore, I think less than ten have reported problems like this. Maybe it's more common than this evidence would suggest, but for lack of evidence to the contrary, I have to assume it's literally less than a fraction of a percent of scores afflicted by this.

I still can't say for sure it's the barlines. The calculation of measure widths is definitely off for those measures, and although we do try to correct for it later, it's still off because we calculate the width of the barlines wrong. But when I correct that, we're still off by just enough that the problem doesn't go away. So I'm still investigating what else might be throwing things off.

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