Measure number -> measure index

[fosfrancesco]

Measures have 2 attributes:

• number: an integer, starting from 0.
• name: a string, as decided by the person writing the score. Most typically it also contains a number (starting from 1, or 0 for pickup measures), but not necessarily always increasing, like in the case of a measure that was split into two parts. Sometimes it also contains other characters, for example, to mark a volta.

The proposal is to change "number" to "index" to avoid confusion. This will also impact some functions, like measure_number_map.

[huispaty]

(added here just for completeness): Currently, the number attribute represents a running count of measures (tags), irrespective of their regularity or volta endings - thus it starts at 1 and continuously increments. If we want to interpret it more like an index, the renaming would make sense. I'm flexible with either option, feel free to choose.

[neosatrapahereje]

I think that we could introduce the index as a separate attribute and not as a substitution of number. Originally, number was based on the MusicXML specification (as @huispaty points out), and measure number 0 is used for pickup measures. I think we should not loose this property, as it reflects an important aspect of the musical syntax.

[fosfrancesco]

I agree with that, but that is what "name" is for (and it is a string since the user can potentially decide to put other stuff inside, even if it is usually just an integer). I don't think "number" starts from 0 for pickup measures right now.

[huispaty]

It's true, currently number represents something more akin to a count as opposed to a number, and starts at 1, and name exists to handle non-integer measures (i.e. marking irregular or pickup measures).

[manoskary]

After the DLfM 2023 article on Measures, I think a good representation of measure class could contain three attributes:

• Measure Number
• Measure Count
• Next Measure

Should we implement it in Partitura this way?

[huispaty]

As we had just discussed I think their way of representing (and particularly identifying) measures would help us in clarifying the confusion between the current name and number attributes. So I'm fine with you implementing it that way.

[sildater]

Hello! So picking up on this thread, I checked a couple of files, and it seems like the Measure class includes name and number properties since version 1.3 with number always starting at 1 and being an integer and name being catch-all for the rest. As for the IO functions:

• import_musicxml: uses both fields in make_measure
• import_mei: uses the xml attribute in line 976 for number (invalid?), no name
• import_midi: uses score.add_measures which uses both fields
• import_music21: I didn't see that it handles measures at all? (invalid?)
• import_kern: line 344 adds measure with number=0 (invalid?), line 778 parses number from the encoding (invalid?), no name (this is a different issue but I saw it in the previous lines: repeats are not handled at all in kern import?)
• import_dcml: use both number and name with corresponding fields in the tsv file.
• import_match: line 759 uses a Measure with number=0, then score.add_measures (invalid?), measure attributes in the match files are unused (see also #246)
• score.add_measures: looks largely consistent with the Measure class, comment in line 3774 says if existing_measure is a match anacrusis measure, keep number 0, and if any measure already has number=0, it's left unchanged (invalid?)
• note_array_to_score: line 193 uses measure number=0 again for anacrusis measures (invalid?).

There seem to be several inconsistencies introduced by this change. My proposal is to find a clear agreement on what the fields number and name represent (-> an put a short explainer in discussions) and everyone then fixes "their" created functions. I didn't check any output functions, but I expect a similarly mixed picture.

[fosfrancesco]

Good point! I second this proposal