Score including jumps with unanticipated playback
I recently updated one of my scores (both available at https://musescore.com/classicman/scores/64431 and in the attachments below), and I noticed that the end of the playback was not as anticipated. The problem is that the note in the last third of bar 44 (numbered as 47 in the programme) is played even though there is a “Fine” in the preceding bar.
Please note: The attached updated score is made in MuseScore 2.3.2, but the bug is also present in MuseScore 3.0.4.
| Attachment | Size |
|---|---|
| Sonate No. 2, 3rd Movement Opus 2 No. 2 Beethoven.mscz | 37.15 KB |
Comments
I feel uncomfortable trying to answer you, I'm musically semi-illiterate, so excuse me if I say a nonsense: D.C. al Fine?
If there is a corruption you can try to replace the measure (check if it works)
In reply to I feel uncomfortable trying… by Shoichi
Strangely, your revision fixed the problem. However, what I denoted as Scherzo D. C. should have the same behaviour as D.C. al Fine in your attachment. I have another example with a similar behaviour as my attached score above. I have used both D.C. al Fine (rewritten as Menuetto da Capo al Fine) and Fine.
Coincidentally, it is still bar 44!
In reply to Strangely, your revision… by ClassicMan19
Yes, because in recent versions Inspector allows you to specify the function. Probably it is sufficient to replace the measure (47).
(after lunch break) Insert measure, copy&paste, delete measure
In reply to Yes, because in recent… by Shoichi
Thank you very much! I checked the scores you have included, and they worked as intended.
However, the bar number for both of the revised scores were incorrect. Therefore, I decremented the bar number for both the pieces. When replaying the score after this, the bug I have mentioned sometimes now, reappeared. When I incremented the bar number in question in both my original scores, the bug did not appear.
Based on these examples, I suspect that the programme will continue to play the following bar, if they have the same bar number, even though a Fine is added to the first bar. What do you think?
In reply to Thank you very much! I… by ClassicMan19
Ciao, that Marc's opinion would be needed.
I'll try to make a few more attempts shortly. But there will be no fixes for the 2x, just workarounds.
In reply to Ciao, that Marc's opinion… by Shoichi
If I change the 'Fine' measure number (-1) and reset measure 44(47) to zero, the problem seems to be solved.
In reply to Ciao, that Marc's opinion… by Shoichi
FWIW, I have no insight into the code having to do with playback of repeats, so I'm not really the best person to weigh in here.
In reply to Thank you very much! I… by ClassicMan19
The issue seems indeed induced by the -1 given to the following measure, somehow making MuseScore think this is the same measure in this regard.
Rather keeping the offset at 0 but checking Exclude from measure count for the second part of the split measure does result in the correct behavior.
In reply to The issue seems indeed… by jeetee
Curious, I wonder how many other playback glitches could be related to this.
In reply to Curious, I wonder how many… by mike320
I'm currently reading through the code to understand this, it could be that it only actually affects jump instructions where two consecutive measures have the same resulting number. Although I think that at the time I wrote this, I referred to "internal" measure numbers, which shouldn't be affected by this values (but perhaps memory serves me wrong here…)
In reply to I'm currently reading… by jeetee
Found root cause, nap time now and no development environment set up locally yet, so filed it as #285870: RepeatList should use measureIndex instead of measure->no() for now.
It indeed only affects jumps where the jump has to replay a "repeatsegment" of the score where the endpoint of the part to repeat and the measure immediately following it have the same resulting visual measure number.