General Measure Numbers implementation

• Mar 2, 2020 - 07:25

Hello,
I am working on an implementation of measure numbers and would like to ask for some opinions about the implementation.

Current Implementation

Every Measure has a MeasureNumberMode which tells the layoutMeasureNumber function how to add the MeasureNumber element.

limitations

In short, it means that measure numbers can only be shown in this position:
1.png
So:
1) There is no option to center over the measure. It is always placed left.
Documented in this issue

2) You cannot add measure numbers below the whole system. Like that :
3.png
(Related issue) (see also this score)

Combining these 2, it means that the following cannot be done without manually moving all measure numbers (and is the standard in film music)
2.png

Design

Palettes

Adding measure numbers to the palettes would be the first needed thing needed for versatility. Allow users to decide exactly when they want to show measure Numbers by simply dragging them from the palettes. All users should be good with how the palettes work by now, so that would be +1 for user-friendliness.

Inspector

There already has been some work done for InspectorMeasureNumber, but it is empty so it never shows up.
Options the inspector would be:
1) Text style and
2) Vertical placement(Above|Below):
6.png
3) Horizontal placement (Left|Center|Right)

Now, if the user sets the (2) vertical placement to below, it likely that it is to place the measure number below the system, and not below the staff. So there could be another option:

4) System placement (Above system | Below system)

But now, what if the option measure number all staves is on. Then it is probably not what they need and we should hide option 4.

Also, 2 and 4 could also be merged into a single
2) Vertical placement (Above staff|Below staff|Above system|Below system). Would prevent cluttering the inspector, but might be less user-friendly? (less consistent too)

Should there be a
5) Text
Which would simply override the default text provided? See this issue for a use-case

Style Dialog

I would greatly appreciate any feedback on this. This would be what shows up under the style dialog->measure numbers
MuseScoreMeasureNumbersDesign.png

Possible implementations

Who handles MeasureNumbers

When adding a measure number somewhere the element could either be added to the measure like a normal element, or the measure's _nomode could be set to MeasureNumberMode::SHOW.
The latter would be easier to implement but less versatile. The former would add the option to add a MeasureNumber to a note, which might be useful in contemporary music.
In short, this means: "Should measure numbers handle themselves, or should they be handled by their parent measure?"

Gould's words (p. 484 and 237, respectively):

4.png
and
5.png


Comments

I definitely support the idea of being able to place measure numbers below the full system, and also the ability to center. More about that in a separate comment.

But I'm not understanding the point of combining that with a whole new implementation involving palettes etc. There are a couple of not-completely-true statements in the above that seem to be in support of the idea, but they need clarification:

1) the statement "Adding a single measure number to a special measure has to be done with a rehearsal mark" - well, no, as mentioned elsewhere, this is done by setting the measure to always show.

2) the statement "(old) scores splitting measures at the end of a system and showing the last beats of that measure on the following system... In such scores, the current measure numbers implementation wouldn't work at all" - maybe I'm missing something (an example would help, but as far as I know this is handled through use of excluding from count on one half of the measure or the other.

That said, the ability to edit the measure number ("19b" etc) does seem valuable, but I'm not convinced it requires a whole new implementation. This could be an additional Measure Property, and it could be made simple to access by double-clicking the existing measure number.

A reason I'm not crazy about adding measure numbers as palette items is it creates the illusion that this more cumbersome method of doing ordinary things is going to fool people into not realizing there is a much easier way. Like, people who want measure numbers on every measure thinking they need to do this manually rather than simply set the appropriate Style option. I'm not generally a fan of having two unrelated ways of doing the same thing without really good reason, and here I'm mostly seeing reasons not to.

In reply to by Marc Sabatella

1) the statement "Adding a single measure number to a special measure has to be done with a rehearsal mark" - well, no, as mentioned elsewhere, this is done by setting the measure to always show.

You are right, I just discovered it myself just now.

2) the statement "(old) scores splitting measures at the end of a system and showing the last beats of that measure on the following system... In such scores, the current measure numbers implementation wouldn't work at all" - maybe I'm missing something (an example would help, but as far as I know this is handled through use of excluding from count on one half of the measure or the other.

I also discovered that one just now.

I'll correct these

In reply to by ecstrema

OK, but then see my comment about wanting a staff property to control display of system elements. I still would not want want to see users tricked into thinking they need to adding things from a palette to get behavior that should be automatable. Presumably you wouldn't want this measure number for just one measure of that staff, you'd want it for that staff in general. If there is some unusual use case where you want a measure number on one measure one staff only, then I think the way to do that would be to add as staff text but assign the measure number style.

In reply to by Marc Sabatella

Assigning the measure number style to staff text wouldn't keep the number in sync. But yes, I guess that for special cases, it could be handled that way. Or, there could be an element in the palettes (that would be hidden behind more).
I see two problems with Measure Properties->Measure Number Mode:
1) It is well hidden/hard to reach/unknown for most users. And even when you know where you are going, it still takes some time to reach it.
2) As mentioned before, it is a property of the whole measure, not of a particular staff. As you said, you'd probably want measure numbers for the whole staff. I cannot find any use case where you could be wrong, but in case something shows up, I don't want to implement it in such a way that it'll be hard to modify if the case arises.

In reply to by ecstrema

I'm a fan of thinking in terms of real-world use cases - we want to automate the common things. If we people have a once-a-decade need for something else, as long as we provide a reasonable way to fake it, I'd rather we go that way than complicate the design for the 99%.

Anyhow, I'm all for exposing the measure properties, probably through the Inspector, for instance. The key to me is making the most discoverable method also be the most automatic method. And while currently measure numbers are not staff-specific, they could be made so, just as visibility is, if there are good real-world use cases for this.

Regarding the parts I do support - placement and alignment options - I do want to see this, but would like to see this solved more generally than just for measure. There are other texts that people might want to place below a system, and other texts people might want to center in a measure. One common use case are the numbers commonly used for repeated measures:

center.png

In this case I have it above, in other cases people prefer them below. I actually made this happen by using "Fine" from the palette, editing the text, and setting the alignment to center - it just so happens we do support center alignment for elements with measure as parent, but this is the only way I know to get that to happen.

So, I want to think about general solutions here that could be used for other elements.

For placement above/below, I do think a new "Below system" value for "Placement" is the most obvious way to handle that. But, I also would like to see a staff property that says "display system elements" so you can have tempo etc repeated above the strings in an orchestral score. So it would be important for these facilities to play nice together.

For horizontal centering, I wonder if we could keep the existing alignment buttons for left/center/right, but add a toggle somewhere to control whether elements are aligned to a specific segment ot to the measure? For measure numbersm this controls whether they align to the barline versus to the measure. For ordinary text, it controls whether there align to the chordrest segment they are attached versus to the measure.

Probably there is a less "clever" way to solve these problems, but these to me seem natural ways to fit this in without major changes to the current use model, and still providing some general

About the style dialog design: the biggest problem is what happens if the first staff is hidden? Should we fallback to the second one? What if that is not what the user wants?

In reply to by ecstrema

Do you mean staff properties? Yes, I would think we should fall back on the first visible staff after that. Hard for me to think of a case where this wouldn't be what is desired, I'd have to see real world score for that. But no one would force you to use the feature if you didn't like the fallback.

Elsewhere there has been discussion of changes to the whole instrument adding/removing/bracketing paradigm. Maybe it really makes more sense to make the "show system elements" into a "bracketed instrument group" property, then it's not really even about fallback, also it could be above or below the group.

The appearance of style dialogue shouldn't depend on the names and amount of instruments, as it is intended to be a place for score styles, not staff/instrument properties. You can probably add the configuration to the Instruments dialogue, but since it's currently being redesigned too, I suggest you wait for now on this matter.

I'm for the idea of specifying vertical and horizontal placement, so I think we can add one more enum class like this:

enum class MeasureNumberPlacement {
      HLeft = 0x1,
      HCenter = 0x2,
      VAbove = 0x4,
      VBelow = 0x8
      };

Similar to Qt's AlignmentFlag. For example default can be MeasureNumberPlacement::HLeft | MeasureNumberPlacement::VAbove.
And I think this can cooperate well with the existing MeasureNumberMode, so the former is for placement and the latter is for visibility. For MeasureNumberPlacement, there can be a score style setting to control that of auto-generated measure numbers, and it can also apply to measure numbers added from palette (unaffected by score style). And since we've come so far, I think it's also necessary to add a generated flag to the measure number class to differentiate generated and manually added measure numbers.

Do you still have an unanswered question? Please log in first to post your question.