Section break pause played after each repetition of a repeat
Context: latest github commit sources self-compiled under Linux Mint 17, with Qt Lib 5.3 and Qt Creator 3.3.0.
Steps:
- open the attached sample score
- make sure the "Play repeats" button is on
- play it
Result
- in the first repeat, which has a vertical frame right after it, the section break pause is played after both repetitions
- in the second repeat, which does NOT have a vertical frame after it, the section break pause is never played.
Expected result:
- the section break pause is played only after the last repetition of a repeat
- regardless the repeat has a vertical frame after it or not
Thanks,
M.
Comments
OK, I forgot the attachment!
This PR may be related: https://github.com/musescore/MuseScore/pull/1707
@Jojo-Schnitz, #2: maybe, the PR description does not quote this specific issue, nor the actual code changes seem obviously related to it.
But, who knows, perhaps Marc can tell something.
I don't think it is about the same exact issue, but somehow related, so I just wanted to prevent collisions.
My guess is the behavior described here with respect to repeats would be unaffected - which is to say, not fixed - by my changes.
However, I am not seeing the frame issue, and that's using the master code - not my fix. Both breaks play for me (on both repeats). Does it work for you if you load the file in question? One of the bugs I did fix was that section breaks don't play at all until after a save/reload or other operation that causes fixTicks() to get called again. So depending on what you did things in when creating that example, it's possible you were seeing what you described in your example before saving it, but had you reloaded, you'd be seeing what I am.
@MarcSabatella: you are right, after re-loading the sample score, the playback is like you describe. To summarize:
This means that point 2) of the "Results" and "Expected results" in the OP are transient and not structural. I have updated the issue title; unfortunately it is not possible to update the original description.
So, we may assume that your pending PR will cure the discrepancy between the before-reload and the after-reload playback; the extra pause playback will remain, though.
I noticed point 1) since long, but never bothered to file an issue. When I decided it was time to do it, I noticed also the second effect and described it accordingly. Sorry for the confusion.
M.
Confirmed issue. Very former...
I see it, with exactly the same characteristic, throughout these almost ten months: until May 19 (2014...!)
For checking:
1) Open this file -> test end repeat.mscz
Result: Playback ok, with repeat
2) Add a section break at the second measure. File: test section break.mscz
Result: always correct. EDIT: well, seems wrong after save-reload :(
3) Insert a vertical frame from the third measure: File: test adding vertical frame issue.mscz
Result: playback stops (during 6 beats) before the repeat. Then stops again 6 beats before continuing to measure 3.
So: for that the question appears, the necessary condition is to add a section break AND a frame. A frame, whatever it is: horizontal, vertical, text (Insert and Append)
Example with the last next file (Append Text frame). Same result thus (and yes, exactly the same, to the last comma... on last May 19!)
test with append text frame.mscz
No problem, took me quite a while to sort out what was going on - as you can see from my description in that PR, there are a *lot* of issues with playback of pauses (including both section break and breaths).
I now recall that something like your repeat case was reported before. So actually, I believe this is a duplicate of #32696: Section break causes pause before repeats and jumps during playback.
Automatically closed -- issue fixed for 2 weeks with no activity.
Automatically closed -- issue fixed for 2 weeks with no activity.
Automatically closed -- issue fixed for 2 weeks with no activity.
Automatically closed -- issue fixed for 2 weeks with no activity.
Automatically closed -- issue fixed for 2 weeks with no activity.
Automatically closed -- issue fixed for 2 weeks with no activity.
Automatically closed -- issue fixed for 2 weeks with no activity.