Changing measure-global "number" to "label"

[adrianholovaty]

Inspired by the discussion at #447, I realized the measure global "number" object is problematic. It's supposed to be the measure's visual label. Some realizations:

• It's semantically different than the other uses of measure number (which refer to the index of the measure within the document).
• It isn't necessarily a number. Measure labels like "32(a)" and "32(b)" are valid, for example in repeats and alternate endings.
• It would be nice to encode additional metadata about the measure label, such as styling, positioning, show/hide decisions, _c comments, etc. I believe measure.number is a holdover from older MNX thinking, before we started to prefer having full object dictionaries to be forwards-compatible for new features.

I propose we rename that "number" to "label" and create a new type "measure label", a dictionary instead of a number. At the moment it would have a single attribute "text", plus the global attributes, with room for adding more down the road.

Thoughts?

(This is distinct from the separate discussion in #447 regarding changing 1-based measure numbers to be 0-based.)

[rpatters1]

Just to pile on, measure "numbers" in Broadway shows are more like every-measure rehearsal marks. They become fixed fairly early in the process. Subsequent deletions result in non-sequential numbering, and additions add letters 31A, 31B, 31C, 31Ca, 31Cb, 31D, 32...

As I understand it, this allows everyone in the production always to refer to the same moment (without having to relearn changed measure numbers), no matter how much the music is revised.

Of the two programs I am familiar with, Finale provides more options. Different ranges of measures can have different numbering styles. But just visually:

• prefix and suffix strings
• numbering (or lettering) styles
• SMPTE time codes rather than numbers
• x/y positioning relative to staff and measure frame
• font style
• enclosure (box or ellipse, usually)

[samuelbradshaw]

Agreed that "measure number" or "measure label" needs to be distinct from measure index. A couple of common patterns in music I work with are:
– Pickup measures are sometimes numbered as "0", and the measure doesn't have a label that's visible to the user.
– In space-constrained sheet music, system breaks are often placed in the middle of a measure, which creates two measures. The two measures might have the same number, or they might be numbered 2A and 2B.

[samuelbradshaw]

I like MEI's "number-like" data type:
https://music-encoding.org/guidelines/v5/attribute-classes/att.nNumberLike.html
It makes it clear that the field is generally expected to be sequential, but not necessarily numeric.

[rpatters1]

Can a "number-like" field be converted to a canonical numeric value? (I can't tell from the description.) Here's the issue for importers, suppose the label is [32B]. In this case (used on Broadway shows ubiquitously) the sequence is actually the letters A, B, ... How is an importer to know this?

[samuelbradshaw]

Good question, I'm not sure how it's used in all cases. My assumption (without having tested) is that number-like could include things like roman numerals (i, ii, iii, iv), section-chapter numbers (1.1.0, 1.1.1, 1.1.2), secondary numbering (1, 2, 2a), letters (A, B, C), ranges (1–2, 3–5), unicode glyphs (①, ②, ③), other numbering systems (١, ٢, ٣), numbers with punctuation (1., 2., 3.), etc. – mainly intended for human-readable labels, not for machine processing. But I could be wrong.

[mscuthbert]

My preference is to have somewhere, something encoded as type Number (or int in other languages) that makes it mostly obvious what to increment/decrement when a measure is added/removed before it (pace Broadway scores, which is a setting to store elsewhere I'm imagine [probably something in _x for now]). Beyond that one can consider a lot of other string options, including recording the whole display-label "[31A]", or storing a prefix "[" and suffix "A]" which sandwich the Number. I can imagine that an optional sort-key might be helpful as a separate thing (so that 30, [31], 32 sort in that order..)

[mscuthbert]

I like MEI's "number-like" data type: https://music-encoding.org/guidelines/v5/attribute-classes/att.nNumberLike.html It makes it clear that the field is generally expected to be sequential, but not necessarily numeric.

I'm not generally against taking good ideas from MEI, but I don't know that "numberLike" is one of them. As a programmer, I'd much rather know that something IS a number, or something is a string, or something is a string that should capture number groups and sort them numerically ("index9" before "index10"). Like a number does not convey enough information to me about what I'm supposed to do with it.

[adrianholovaty]

I'd definitely support adding an "integer only" component to the measure label. It could look like this:

{
  "text": "31a",
  "number": 31
}

Regarding this...

Beyond that one can consider a lot of other string options, including recording the whole display-label "[31A]", or storing a prefix "[" and suffix "A]" which sandwich the Number.

I know you weren't necessarily advocating for that, but there comes a point of diminishing returns here. I think the practical approach of "allow encoding the integer-only part, plus a fully-formed string" strikes a good balance with the data that's most likely going to be used.

[ahankinson]

“Number-like” is precisely because you commonly have things in music notation that convey ordering that are not actually numbers. “31A” and “31B” are number-like. In this sense, “A” and “B” are also number-like, since it indicates a procession or a sequence. The only thing that is not allowed in a number-like attribute is a space character. There is no way to validate this, but it’s primarily to have a place to store a sequence indicator without limiting what kinds of sequences you have to use. So @samuelbradshaw is correct — they are all number-like.

It is most commonly used for staff and measure numbers, where some measures may be unnumbered (improvised, or even omitted in the case of a part having multiple measures of rest while the other parts do not) or it may have divergent choices (e.g. ossia, reconstructions where an editor has inserted what they think is missing or filled it in from a previous copy).

Deriving an integer number for a measure is pretty easy (just count them! As long as you count them in the same order every time, and update the counting when you add and remove measures…) but deriving an appropriate label is not. I can’t tell if the goal here is to have a label, or to have a unique identifier. If it’s a label, then you will definitely run into non-Arabic numeral systems. (I might just compose a piece for the occasion by numbering my measures in binary, just to see how leading zeroes are treated! :-)

Here’s an interesting blog post about measure numbering I found when writing this reply:

http://www.settlingscoresblog.net/2018/08/34-bar-numbers.html?m=1

This was also an interesting read: https://acmp.net/art-and-science-measure-numbering/

[mscuthbert]

Thanks for the refs Andrew. I guess I don't think of numbers as the only thing that conveys ordering, ABCDE..., conveys an order but I wouldn't call those numbers or number-like. Ensign, Lieutenant, Commander, Captain, Admiral is ordered but not numbered. Same with Picc... Fl., Ob., Cl., Bsn ... Vla. Vc. Cb... -- ordered but not numberLike. Orderable is the trait I'd label as.

---

Only asides below:

This seems as good a place to ask as any (I may have asked once already) -- I remember being taught a rule that a pickup measure which is longer than 1/2 the notated meter retains its number (1) and isn't (0). But now I can't find anyone else who teaches this rule; but I'd love to know that I wasn't insane in remembering being taught it.

(An odd corner case that is always a pain for measure numbering: it was (is?) a custom for band marches to have one instrument play an obbligato part only the second time through the trio (piccolo, clarinet, trumpet often) -- when it's "2nd time only" that's easy. When they have totally different music 1st from 2nd time, it's customary for that instrument to have the trio written out (no D.S. or no repeat mark), so the player, hearing "omit the first repeat" doesn't see anything indicating there was one.)

[samuelbradshaw]

A reason I like the name "number-like" is because these labels are usually called numbers outside of a programming context – song numbers (1, 1a), page numbers (i, ii, iii), section numbers (1.1.0, 1.1.1), version numbers (v1.0, v1.1), measure numbers (1A, 1B), verse numbers (1, Chorus-1), apartment numbers (A100), flight numbers (DL567) – even when they are not strictly integers.

[ahankinson]

I suppose that 90% of the time it will be strictly number-like, so it answers the question of “where in MEI do I put the measure numbers?” But it would also be the same place that you would put “ensign”, “lieutenant” and “commander” if that’s how the composer chose to “number” their measures 😁

(After seeing a clef on a staff space, I am solidly of the opinion that in music notation, exactly what you think will never happen, happens. And if not, somebody will make it happen..)

[rpatters1]

A proposal for numberlike would be a json object with:

• value (a required integer value of its value in the sequence)
• numberStyle (Finale has arabic, roman, ordinal, letters, letterNumbers, smpte) optional defaults arabic
• lowerCase (optional defaults false)
• prefix (optional string)
• suffix (optional string)

The meaning of the number styles:

• arabic: 0, 1, 2, 3 ...
• roman: I, II, III, IV, ...
• ordinal: 1st, 2nd, 3rd, 4th, ... (this gets interesting in its locale variation)
• letters: A, B, C, D, ... AA, BB, CC, DD, ...
• letterNumbers: A, B, C, D, ... A1, B1, C1, ...
• smpte: SMPTE time code

Finale also has 2 forms of letter sequence A, B, ... AA, BB, ... and A, B, ..., AA, AB, ....

If you want to add military rank, you would need both armyRank and navyRank, I believe. But this is outside my expertise. 😛

This would a useful type for rehearsal numbers as well as measures. (Also perhaps part numbering.)

[rpatters1]

Here's our [32B] Broadway show number encoded this way:

{
    "value": 2,
    "numberStyle": "letters",
    "prefix": "[32",
    "suffix": "]"
}

A format like this would be super easy both to import and export in Finale, and it could be imported into MuseScore easily to the extent that MuseScore supports the features. I would think it would interchange easily in many other contexts.

[samuelbradshaw]

I guess I'm not understanding why apps need to programmatically parse this number/label field as an integer, and why it can't be a simple nullable string (or object with a string) that accepts any value. We already have the measure index that indicates the order of the measures.