SOLVED: Problem with skipped Voltas
In a post the other day I indicated issues with D.C. in a repeat with an additional issue that I could not get the intended logic of the composer playback properly. By serendipity, I was looking at some playbacks with more than two voltas and stumbled across a solution which raises some questions about playcount and playback.
I submit two image files and a sample score. The image file Skipped Voltas displays a schematic of how I believe the composer intended the music to be played in the first repeat; play first two endings, skip the third, and then on the d.s. pass (composer has a d.c.) play only the third ending and exit the section. I was unable to find any way to implement this action (although I did come up with a method involving a jump to coda and relocating the location of the measure with the third volta to end of the section. Not sharing screwball option in this note.) What I discovered is that the implementation displayed in the MixedUpVoltas image works in playback and is contained in the Musescore file. Essentially the implementation is to use a standard three volta repeat with two end repeat bars. The key to making it work is that the measures with voltas 2 and 3 are interchanged such that the volta values are not in order 1,2,3 but in order 1,3,2. Obviosulsy the notes move as well. The Fine is under the volta with the 3. (but appears as second volta left to right.) When played the normal pass with measure count 2 finds the third volta (value 2) which has no repeat so the music continues. When the D.S. al Fine pass is implemented (without repeats) the second volta from left to right is played (the one with the 3) and the fine is found. I cannot explain the coding but I assume that since the normal pass only reached playcount of 2, that when determining which volta to play it plays the second volta. (The one marked with 3.) The only time this measure plays is on the exiting pass to the Fine which is what I wanted to achieve. Under normal conditions, say with 1,2,3 in normal order the playcount reaches 3 and this is also the 3rd volta so it is in fact the final volta, but I present a situation where the volta played is not the final volta.
| Attachment | Size |
|---|---|
| MixedUpVoltas.jpg | 50.81 KB |
| Skipped Voltas.jpg | 93.17 KB |
| MixedUpVoltas.mscz | 13.09 KB |
Comments
What was the solution?
In reply to What was the solution? by Jojo-Schmitz
creating second end repeat and interchanged the order for the measures covered by voltas 2 and 3 such that the order was 1,3,2 and the corresponding notes for those measures move too. The Fine is in the second volta with value 3.
You're likely referring to your previous post being https://musescore.org/en/node/313743
Note that what you were looking for are workarounds for two bugs that are fixed for the next release. Your initial score in that thread simply plays back correctly in the latest nightly builds.
In reply to You're likely referring to… by jeetee
I believe the problem in that post had to do with two measures in a volta not playing properly (only second measure.) The other issue was that the inclusion of the D.C. in one section caused the next section repeat to not play at all (it played like a final playback without repeats checked.) This issue is slightly different. I had a number of issues and may have not referenced them correctly.
In reply to I believe the problem in… by msokol
This issue is slightly different. I had a number of issues and may have not referenced them correctly.
To facilitate testing, and to help confirm that the bugs are fixed in the latest nightlies, could you re-attach here the 'broken' versions of scores (those not using your workarounds) having the slightly different volta issues.
I would like to test them in the nightly.
In reply to This issue is slightly… by Jm6stringer
Per your request. This is a real score, not a synthetic demo of a pattern like my initial uploads. Note the problems are with sections No. 1 and No. 2 which both use the same settings as the repeat pattern is similar. I have increased the tempo for these so they play faster. I am uncertain of the play count to set before the end repeat in the first volta. I have a value of 2. My thought was that I only want two times through during normal pass. But documentation says it should be 1 greater than the number of choices (hence 3) for the volta set at 1,2 in the playlist. None the less with a value of 2, the final D.C. pass works okay until the final voltas. In this situation both measures of volta 1,2 play (the one with D.C. ) and only the second measure of the second volta plays. First measure of second volta does not. If I change the play count to 3, interestingly there are only 2 repeats initially as the D.C. jump occurs after the second pass. I do not understand when the jump is calculated to occur. In this situation, the voltas play differently on the D.C. pass, with the second measure of the first volta, and both measures of the second volta effectively skipping measure 1 of the first volta. The desired result is that only both measures of the second volta play. BTW.. I have had some playback issues if I start and stop playback short of the normal ending and then start the playback at the beginning of the section. I get funny repeat patterns. To make sure, I have started the playback a measure or two before the No. 1 section and insure I entered the section cleanly. The funny behavior is not always reproducible and have noticed this in testing other scores in the past.
In reply to Per your request. This is… by msokol
If you restore the play count for those first volta's in No 1 and No 2 to have a value of 3, just as the manual indicates, then that plays back without flaw in what-will-be 3.6.
> "I do not understand when the jump is calculated to occur."
A jump is taken on the last normal pass of the measure containing it. So for a jump under a volta, that is at the playthrough matching the highest number in the repeatlist of that volta.
In reply to If you restore the play… by jeetee
Understand how the jump occurs now. What controls which volta is played. Is it last in the row or one with the hightest test value? If the order is not such that the highest test is in the final volta, I am able to create a situation where the volta played during d.c. or d.s. is not the last one. See my other note which you commented in about Playback issues with D.C/Voltas.
In reply to Understand how the jump… by msokol
In order to determine the "last" playback you have to regard all the end barlines matching up with the start repeat (or start of the section if no prior start repeat). Volta repeat lists themselves are not considered in calculating what the last repeat is; they are only compared to the result of the calculation.
This is why it is important to set the correct playback count for those bars containing the end repeat barlines.
In reply to Per your request. This is… by msokol
Sections No. 1 and No. 2 play just fine in the latest nightly.
Jumps (e.g., D.C., D.S.) from inside a volta are fixed, as jeetee has mentioned, so sit tight and wait for the ver. 5.6.0 release.
You wrote:
My thought was that I only want two times through during normal pass. But documentation says it should be 1 greater than the number of choices (hence 3) for the volta set at 1,2 in the playlist.
Be aware...
The playcount must be set to 3, as per the documentation, when your score is (eventually) loaded into 5.6.0 for the voltas to work correctly.
Also, what's up with measure 16 of the No. 2 section? It sounds like the 'record skips'.
(Compare it to the smooth transition from No. 2 to No. 3.)
In reply to Sections No. 1 and No. 2… by Jm6stringer
As for skipping here are my observations. No 2 should be identical to No 1 as far as repeats, jumps and endings. In my "corrupted" version it plays the same patterns when the play count is set to 2, which you say is not correct This is the score I posted. However, the result of the jumps and repeats is correct, only the handling of the voltas on the final repeat are not correct. If I change the play counts to 3, No 1 plays correctly. No 2 plays the initial pass of repeat 1 correctly (2x) but then plays the second repeat as if it is in a D.C. pass and plays only 1x and takes and exits playing the voltas with the known issues. I mentioned this in my other post on Playing D.C/Voltas. I believe you may see No.2 play correctly if you remove the D.C from No. 1. That is why No. 1 is okay .. there is no similarly patterned section prior to it. This is one of the "bugs" I discussed but maybe not explicitly in this thread. This is why I suggested some corruption where a flag is not being reset properly for whatever reason. I believe this behavior was illustrated in the music files I I posted with simple patterns initially. Again I am playing with 3.5.2.
In reply to As for skipping here are my… by msokol
Voltas containing jumps is fixed for the next version that will be released. That's where you must enter 3 for the play count.
MuseScore version 3.5.2 will always have the bug you encounter. It will never be fixed so, for now, you can use whatever 'workaround' you are happy with, for playing with 3.5.2.
When version 5.6.0 is released, your 'workaround' won't work unless the play count is set to 3 (i.e., according to the documentation) because version 5.6.0 no longer has this bug.
The skipping part relates to measure 16 of the No. 2 section. Listen to the score starting a few measures before and play until a few measures after. Using the metronome may be of help to hear the irregular 'skip'.
See:
https://musescore.org/en/handbook/measure-operations#duration
for information about matching the pickup measure with the complementary measure.
In reply to Voltas containing jumps is… by Jm6stringer
version 5.6.0
Better known as version 3.6.0 ;-)
In reply to version 5.6.0 Better known… by mike320
Ha!
Should be 3.6.0 indeed. Thanks.
Looking ahead though...
5.6.0 will require a HIP replacement (Human Interface Port) as the deprecated step-time is being replaced by a new thought entry mode.
(Windows XP users are not happy about this.)
In reply to Voltas containing jumps is… by Jm6stringer
Fixed the skip. It was a typo on my part .. had two 1/8 notes ending the measure not 1/8, 1/4 So I dropped the measure property to remove the rest when in reality the rest should have been removed by fixing the note duration. Sorry for the inconvenience and thanks for you help and explanation. So in the grand scheme of things, the volta played during jumps when play repeats is not checked, assuming all the rules on play count and repeat bars are followed, will be the rightmost volta, which will be the one appearing over the measure following the last repeat bar. This is regardless of the playlists on the voltas themselves.
In reply to Fixed the skip. It was a… by msokol
Almost there..
The volta that will be played is the ones that have an entry in the repeatlist matching the calculated count of what the last repeat is. Let's take the following example:
![313920-repeat_example.png]()
The resulting playback is 1-6, 3-4,7, 3-5, 1-4, 8-9
Let's break it down.
1-6: First playthrough, so the volta is honored, the jump is skipped as this is not the last normal playthrough of its containing measure and the end repeat is encountered. The number of repeats has not yet been reached for this end repeat, so we will follow it, back to the matching start repeat reference point.
3-4,7: 2nd playthrough, we skip the first volta (no match in repeatlist) and honor the 2nd volta as the repeatlist matches the playthrough count. We reach the end repeat barline and have not yet exhausted its number of repeats, so it is honored and we follow it back to the matching start repeat reference point.
3-5: 3rd playthrough, we honor the first volta (matching entry found in the repeatlist). This time we're at the "last normal" playthrough for the measures it spans over, as we matched with the highest value in the repeatlist of the volta. This also means that the Jump is now honored and we execute the D.C., throwing us back to the beginning of the score. As the D.C. has no repeats enabled, it will result in forcing the "final" playthrough of the piece.
1-4, 8-9: 1st and 5th playthrough (sum all end barline (playcount-1) matching with the start barline to figure out the final playthrough. For m1-2 this sets the playthrough to a value of 1; for m3-9 this sets the playthrough to a value of 5.
As a result, both the first and second volta are skipped, as neither has a repeatlist entry matching the value of 5.
It's a fairly "strange" example, but it does bring together all of the elements in play in your understanding here.
If you're really interested into the further finesses of how interpretation works, but don't feel like reading code, you can take a look at the test scores we use for automated testing. They all contain a specific scenario (or combination) and show the intended playback order in a text frame just below the title frame.
Those scores (currently 66!) can be found at https://github.com/musescore/MuseScore/tree/3.x/mtest/libmscore/repeat
In reply to Almost there.. The volta… by jeetee
Appreciate all the time in responding. I tried to view the git hub site. All the files are .mscx not .mxcz and contain code not scores.
In reply to Appreciate all the time in… by msokol
These are scores, just uncompressed
In reply to Appreciate all the time in… by msokol
Those mscx are also scores, but in the uncompressed variant (which makes comparing them in automated tests so much easier).
You can directly open them in MuseScore without issue. Just note that for tests 65 and 66 you will need get a warning when opening them in 3.5 as they were created during 3.6 development specifically to address and test for the bugs you've discovered.
In reply to Those mscx are also scores,… by jeetee
When I try to open them in 3.5.2 I get a message saying file corrupted. I also get it when double clicking on the .mscx file.
In reply to When I try to open them in 3… by msokol
Forgot to mention. If I say Ignore it continues but I just get a blank, dark blue screen.
In reply to Forgot to mention. If I say… by msokol
Hmm.. I see they were all very recently updated for the 3.6 file format.
Try this set instead: https://github.com/musescore/MuseScore/tree/3.5.2/mtest/libmscore/repeat
Those were the tests as existing when 3.5.2 got released in the 3.5.2 fileformat. You'll notice there are only 57 of them, because thanks to people such as yourself we've been able to track down and fix a couple more bugs in the meantime.
In reply to Hmm.. I see they were all… by jeetee
Same problem. Not sure about JoJo's comment about read again other than implying that they should be files that MuseScore can open.
In reply to When I try to open them in 3… by msokol
No, read again.
In reply to No, read again. by Jojo-Schmitz
I do not get that message.. Just one that says file corrupted. Same problem with the files from the 3.5.2 archive suggested to use instead of the 3.x archive.
In reply to I do not get that message… by msokol
What version of MuseScore are you using then?
Try these
In reply to What version of MuseScore… by Jojo-Schmitz
N.B.:
"repeat65.mscx" and "repeat66.mscx" contain new fixes and so only work properly in prerelease version 3.6.0.
The others play fine in 3.5.2.
In reply to I do not get that message… by msokol
Then your download went wrong
In reply to Then your download went wro by Jojo-Schmitz
The four attachments in the previous response worked okay. Two opened and two open the message about a later version of MuseScore. Thanks all.
In reply to The four attachments in the… by msokol
I went back to the archives and instead of saving the *.mscx target file as a file to initiate a download, I copied the XML when viewing the file to a text file and named it as an .mscx and the file opened okay in Musescore. Something about the file transfer that normally works perfectly in pulling files from websites where the file name appears as a link did not work in this instance. There were no other buttons or actions identified for a file download. Not sure how you guys pull them but perhaps it was via the Github desktop which I do not have installed.
In reply to I went back to the archives… by msokol
The reason the download was "corrupted" is that when viewing the github site with the listing of the various uncompressed files, the link is not a link directly to an *.mscx file but rather a link to a web page that displays the xml file listing along with whatever else is on the page. Thus when you tell windows to save the Target (xxx.mscx) as a file with that name you are saving an HTML file not an XML file. There was nothing that showed me how to download the file directly from the archive.