GSoC 2020 Week 5 Recap: Laying Out Measure Repeats

Posted 3 years ago
Previous post Next post

Update from last week

My goals for last week were as follows:

  • Expand MeasureRepeat class to support varying numbers under the hood
  • Draw the MeasureRepeat from the font instead of with a hard-coded path
  • Make all current uses of MeasureRepeat specify that it is the one-measure version being called (i.e., keeping same functionality, but changing implementation)

I did all of that in the first couple of days, and went on to, well, take those under-the-hood changes out from under the hood. Here's a demonstration of the current level of functionality:

To get here, I consulted with my mentor and we figured out the essential architectural concept: the measure repeat consists of the symbol, which is only attached to one measure, and then the possibly two or four measures which are treated as a group associated with the measure repeat (grouped with the "Group Measures" element I worked on earlier). Thus, it was necessary to make measures aware when they were they are part of a measure repeat group. In addition, since measures cannot be entirely empty but must at least hold a full measure rest, those rests must be present but not laid out when they are in a measure repeat group.

The way I have this implemented currently, each measure knows how to find the first measure of the group, and that's enough; knowing the total number of measures and the place where they start, they can all be reached when needed.

It is also worth noting that I used only two positioning algorithms—the measure repeat symbol can be either centered within the measure or centered over the barline at the end of the measure—and for the four-measure repeat, it simply gets attached to the second measure of the group rather than the first.

Here's the MSCX code for a four-measure repeat. Note that each measure has its measureRepeatCount, showing that it is part of the group, and the MeasureRepeat itself, with subtype 4, is in the second measure. (The MeasureRepeat holds a faux "duration" because it is occupying the place of a rest in the second measure; I will probably revise this implementation further and make it merely an element attached to the measure, in addition to, rather than instead of, a full measure rest.)

All of this is meant to be as automatic as possible. So, for example, everything to do with creating the measure group is handled at the same time that the MeasureRepeat is inserted, and everything to do with making the measures independent again is handled at the same time that the MeasureRepeat is deleted. At the moment, as seen in the video, there's the rather serious problem that this doesn't happen when undoing an insertion or a deletion.

Looking forward to this week

Priority 1 is figuring out the undo/redo system and fixing that rather serious problem. Priority 2 is figuring out and fixing the glitch that happened while I was recording the video. After that, there are any number of things that could be improved:

  • Making the MeasureRepeat merely an element attached to the measure, in addition to, rather than instead of, a full measure rest
  • Warning the user if adding the MeasureRepeat will cause existing content to be cleared out of the way
  • Deleting symbol and ungrouping measures (with a warning) if user tries to enter notes within the group
  • Adding Inspector properties to show/hide outriggers, as well as the numbers
  • Including the numbers in autoplace calculations (currently left out because it distorts the width of whichever measure the symbol is attached to)

Etc.

Work will be pushed here: https://github.com/IsaacWeiss/MuseScore/commits/gsoc-2020-measure-repea…

Previous post Next post

Comments

Great job once again!

I think we could go either way on the question of making that symbol a rest that belongs to the segment as you have it (and thus has a duration etc) vs attaching it to the measure directly. The advantage of what you have is we don't need to do anything else special to handle the measure being empty otherwise. Although, I guess, in the four-bar repeat case, there are a couple of completely empty measures no matter how you slice it. So maybe no big deal.

I don't think either of the problems (undo or disappearing clef) will turn out to be anything complicated, probably more time searching for the solution than actually writing code to solve it.

Hi Isaac, not sure if it's the right place here to report it, but as far I can see it's your last blog entry. Concerning repeats: Some years ago I reported that it isn't possible to use "d.c. al coda" resp. "d.s. al coda" by using a section break between the necessary elements - "to coda", "coda sign". In my case it was a work of Bach where I wanted to return to a former movement and jump forwards to the final movement.
I didn't check if it's fixed meanwhile, but maybe also worth to take a look of it with your gsoc project.

In reply to by SteveBlower

Yep, maybe you're right, it isn't best place to report it for measure repeats. But as far I followed with this gsoc project the aim is also to handle repeats in general.

Also correct: I noticed this issue, when I transcribed several movements with MuseScore 2, each in a single score, joined these scores with the album manager, added a section break between, but wanted to repeat a movement of it again and jumps forwards again later inside the joined score.
So I'm not sure if it's a repeat issue or an missing album manager issue.

In reply to by kuwitt

If you have been following the GSOC blogs you will see that this project is about measure repeats and "old style" multimeasure rests. Nothing to do with section repeats, DCs Codas etc. It is more likely that an audience for discussion about those will be found elsewhere.

In reply to by SteveBlower

I only follow the actual gsoc projects from time to time. In this case the main purpose probably really is about the playback of multi measure repeat symbols or handle the appearance of "old style" multimeasure rests. In my personal opinion jumps are also an issue of measure repeats, but maybe this discussion should take place somewhere else concernig the correct roadmap of the playback, so maybe I'm confused about this gsoc project.

Looks good.

Quick question, in addition to "Adding Inspector properties to show/hide outriggers, as well as the numbers", will we also be able to change the measureRepeatCount there to be any positive integer? Also for odd-number of measures of repeat, would the measure repeat symbol appear in the middle of the middle measure? (Sorry if these questions might have been answered somewhere else)

In reply to by ericfontainejazz

I decided against allowing changing their type once added to the score, because the Inspector normally changes more surface-level properties. Also, I'm convinced of the nonstandardness, and thus inadvisability, of the "any positive integer" approach; as I mentioned in my initial blog post, even SMuFL only gives three symbols (one-, two-, and four-measure repeat). That said, I can state with confidence that if in future years such a notation comes into use, the techniques I'm using under the hood will allow that extension fairly easily. One example of this is how the one-measure repeat appears in the middle of its measure (the "middle" measure 😉), and any other odd number could be positioned the same way.