Trills visually change location and/or note hangs after it's finished
Greetings,
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.
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).
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 |
Comments
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 In order to investigate, we'd by Marc Sabatella
https://musescore.com/kiffern3/dixieland-strut
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 https://musescore.com/kiffern 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 Yes, this seems to be exactly by Marc Sabatella
Adding a page spacer fixed most of the trill-line problems, but the crescendos are still "alive", moving away.
In reply to Adding a page spacer fixed 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."
and
"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 "The problem can be 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 "The problem can be by cadiz1
The trill problem is mostly solved now by the page spacers, and layout change doesn't seem to help. The crescendos still change location though.
I will edit the post.
In reply to The trill problem is mostly by Kiffern III
We are talking about this score, right? : Dixieland_Strut.mscz
In reply to We are talking about this by cadiz1
Yes, that's the score.
In reply to Yes, that's the score. 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?)
@Marc
"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 @Marc "This isn't something by DanielR
Could you please attach one of these scores showing this, and by providing precise steps for reproduce?
In reply to @Marc "This isn't something 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 I understand it is persistent by Marc Sabatella
Marc,
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.
Dan
In reply to Marc, I have just 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 I understand it is persistent 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 Update: I have confirmed that 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 In my experience this problem 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.