Da Capo/Da Segno al Fine ignore next section on playback

It did not exist in 1.X, because that had no section break... We'd need the implicit "start" and "end" tags to be section aware, the Fine too

Please provide a short example to demonstrate the problem.

Assume Movement A, section break, Movement B, section break, Movement C.

Movement B has a D.C.
Expected result: it plays Movement B again, then continues with Movement C
Actual result: it plays Movement A, then B, then C

Movement B has a D.C.al Fine
Expected result: it plays Movement B again, up to the Fine, then continues with Movement C
Actual result: it plays Movement A, then B up to the Fine and stops.

Movement B has a D.S. al Fine
Expected result: it plays Movement B starting with the Segno, up to the Fine, then continues with Movement C
Actual result: it plays Movement B starting with the Segno, up to the Fine and stops.

Duplicate of #16397: Da Capo ignores section breaks, but I'm not sure which of the 2 to close

Assume Movement A, section break, Movement B, section break, Movement C.
Movement B has a D.C.
Expected result: it plays Movement B again, then continues with Movement C

This is debatable. If the user wants to go back to B, it can use a segno and a DS. Hide, change the text accordingly.

Movement B has a D.C.al Fine
Expected result: it plays Movement B again, up to the Fine, then continues with Movement C
Actual result: it plays Movement A, then B up to the Fine and stops.
Idem, one can use a DS al fine in this case.

Movement B has a D.S. al Fine
Expected result: it plays Movement B starting with the Segno, up to the Fine, then continues with Movement C
Actual result: it plays Movement B starting with the Segno, up to the Fine and stops.

One could change the Fine by To Coda.

If we change the behavior of DC and Fine to be "section aware" then users who want to replay two sections will have exactly the same issue...

Hmm, now think join single file movements via album feature and all of a sudden your repeats don't work anymore
Ad sections are what they are, sections, to be played one after the other (but doing their own repeats stuff inside). If that is not desired, remove the section break (and optionally modify the 1st measure's number of the 2nd 'section', hide courtesy key and time sig etc.)

I am inclined to agree with Jojo - while section breaks could possibly be used for purposes other than separating movements or individual songs within a collection, those are the main intended purposes, and it would be nice if playback reflected that scenario.

I'd like to fix this, but first I want to agree on expected behavior. I agree with Jojo & Marc here, but seems lasconic has slightly different interpretation.

The handbook doesn't have a hard definition as to what precisely a musescore "section break" is. The breaks-and-spacers page says "Section Break can be used to separate movements in a concerto for example..." and talks about some things it does like reset measure numbers, and the album page says "section breaks are added to the last measure or frame of each score in the combined file" (which could be a collection of movements or any arbitrary collection of scores of roughly the same template). So then what is a section break?

I think the essential definition/purpose/functionality/interpretation should be that a section break *partitions* a score. Using this interpretation, I would agree with jojo#1 "We'd need the implicit "start" and "end" tags to be section aware, the Fine too" and jojo#8 "sections are what they are, sections, to be played one after the other (but doing their own repeats stuff inside)".

I would phrase the expected behavior like this: the repeat list of a score with section breaks should be exactly equal to the concatenation of the repeat lists of each section enclosed by section breaks (as if they were each treated as their own score). In fact, my fix for this bug (if I get the goahead to fix it) would be basically that...I would enclose the bulk of RepeatList::unwind() with an outer loop that partitions the score according to each section_break, and handles unwind logic for each section independently.

Now what if a section has a jump that references a marker outside of its section? Well then according to my intrepretation, I would treat those markers as invalid and would basically have those jumps not do anything, according to #66946: Null/Empty/Invalid Jumps should either not interfere with playback or should report error, and maybe mark them red according to #67211: Invalid strings for "Jump to", "Play Until", and "Continue at" should report error and/or displayed Red.

Well, essentially a section break starts a new piece (or a collection or songbook) or movement (of a larger piece). And as measure numbers start counting from 1 again after a section break, so should repeats and jumps, and stay within their section.
At least that's my opinion ;-)

A jump to an outside marker may still be allowed though, if it exists and is unique across the entire score

regarding a jump to an outside marker, I did think about that, but worry that allowing that would complicate matters. EDIT: I suppose could allow jumps outside of sections, but may not "officially" support it.

Or rather not officially prevent them ;-)

:) would essentially be unoffical, undocumented behavior.

I'm going to implement my fix. I will allow jumps to outside marker.

I haven't heard a response from lasconic on this thread...maybe he is not following, but I suppose he'll be able to object in the pull request. Regarding his response #7, if user wants to go back to an earlier movement when encounter a DC in a later movement, my implementation will require them to create an invisible marker at the beginning of the earlier movement to jump to. But the default behavior will be to jump to the start of the current movement.

https://github.com/musescore/MuseScore/pull/2165

OK, I have the repeat test passing for a giant album of all previous repeat tests joined together (with section breaks between). I closed my previous PR, in favor of my updated PR: https://github.com/musescore/MuseScore/pull/2172

I've updated PR to take into account fact that section breaks may occur on non-measure MeasureBase objects like frames. Attached is a repeat test for that, however I need to fix #73801: SECTION_BREAK on non-measure MEASURE_BASE does not reset measure numbering in next section in order for travis to actually pass the test, because measure numbers need to be reset upon section breaks.

I believe one of the concerns about my new PR is that it changes the behavior of scores that already have a DC after a SECTION_BREAK, such that the playback with my PR would repeat not to the beginning of the score, but to after that section break. If this is a concern that is holding back adoption of my PR, then maybe I will offer to modify the .mscx import code for 2.0.2 and earlier by adding an invisible marker at the beginning of the score with a new label and have any DC's in that imported file rename the jump to label to point to the very start of the score.

Fixed in branch master, commit 11362dbe35

Fix #65161 repeatlist unwind section by section _rebased

Each section is unwound individually. A giant album should have same repeat list as concatenation of repeatlists from individual scores (provided each score only refered to markers in its score).
Partitions score by section breaks, and is now aware about section breaks occuring on non-measure MeasureBase objects such as horizontal/vertical frames (repeat37 test).

Fixed in branch master, commit 41e9bdc609

Merge pull request #2172 from ericfont/65161-repeatlist-unwind-section-by-section_updated

Fix #65161 repeatlist unwind section by section UPDATED

Fixed in branch 2.0.3, commit 634c89bf0c

Fix #65161 repeatlist unwind section by section _rebased

Each section is unwound individually. A giant album should have same repeat list as concatenation of repeatlists from individual scores (provided each score only refered to markers in its score).
Partitions score by section breaks, and is now aware about section breaks occuring on non-measure MeasureBase objects such as horizontal/vertical frames (repeat37 test).

Automatically closed -- issue fixed for 2 weeks with no activity.