Open fosfrancesco opened 1 year ago
(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.
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.
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.
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).
After the DLfM 2023 article on Measures, I think a good representation of measure class could contain three attributes:
Should we implement it in Partitura this way?
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.
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 nameimport_midi
: uses score.add_measures
which uses both fieldsimport_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.
Good point! I second this proposal
Measures have 2 attributes:
The proposal is to change "number" to "index" to avoid confusion. This will also impact some functions, like
measure_number_map
.