To complete the descriptions of the keys, I propose for 'next' (here) :

"description": "The bars that follow this one, in performance order, expressed by their 'count'. Most bars have exactly one entry in this list; those before a repeat may have two or more. The value -1 refers to the end of the piece.",
"examples": [
    [2],
    [9,1],
    [59,-1],
]

I could not push the change / another branch for the moment. Is there some rights to grant so I can contribute to it?

What are the specification for compressed / uncompressed? The aim is to keep only necessary information without any loss of information.

• First of all, a fully compressed version is also non-verbose (see non-verbose specification #2 (comment)): the only values that are written are those that are different from the default values.
• If a measure can be entirely deduced from the previous one, then it does not appear in the compressed measure map. The following displayed measure must mention its number so that we can deduce how many measures were skipped this way.
• The last measure of the original measure map is always put in the compressed measure map -- with its 'number'.
  • (An alternative solutions have been proposed to indicate endings: an end-of-piece token with qstamp indicating the length of the piece in quarter notes (and 'count' -1 ?))

Remarks/questions:

• 1- We mentioned that having specific ID for each measure involves that they all need to be in the measure map (i.e. no compression possible). Should we discourage this practice, or accept to lose this information in some cases?
• We have a short compression example in the article [{'time_signature': 'cut'}, {'number': 563}]:
  • 2- Why do we put 'number' instead of 'count'? It gives information on the numbering (more on the 'logical' side), but the length of the piece is harder to read if we have - let's say - a split measure. Wouldn't 'count' be more robust? : see Mathieu's answer
  • 3- In the first measure, the count is not mentioned. This is not a major problem since we can easily deduce its default value is 1. Nevertheless, current json schema impose that we have at least count or id: should we reconsider this, or allow compressed versions only to break the rule? (or add counts to compressed!)

For each key in the schema, we can define default values so that only 'important' keys are needed. (This is different to 'compressed' version which also erase entire unnecessary measure). Besides, could some of these default values be part of the schema?

Current proposition:

• count : <previous 'count'> + 1, and to 1 for the first measure (cannot be overridden)
• id : defaults to current 'count' (converted to str)
• number : defaults to <previous 'number'> + 1, and to 1 for the first measure
• name : defaults to current number (converted to string) ; if previous name is in the form of a number followed by a single letter (e.g. "19a"), the same letter is added on current name ("20a") (edit: see #3 (comment))
• time_signature : defaults to the previous time_signature, and to null for the first measure
• nominal_length : defaults to 4.0 * numerator/denominator based on current time signature
• actual_length : defaults to current nominal_length
• qstamp : defaults to <previous 'qstamp'> + <previous 'actual_duration', and 0.0 for the first measure
• start_repeat : defaults to False
• end_repeat : defaults to False
• next : defaults to [<current 'count'> + 1], and to [-1] for the last measure

A verbose version can be easily built by iterating on each measure to add default values for missing keys -- in the order above ; using both previous and current measure's info.

Any changes to consider before integrating this as official specs?

I regroup few issues or questions about handling the repeats keys (start_repeat and end_repeat)

In this file, measure 8 mentions (accurately) "end_repeat": true and continues to measure 1; however, measure 1 have "start_repeat": false. It should be true, right?

Similar issues appears in _measures.tsv files from ms3, like this one (line 21 should have a start repeat), but the problem is more on the side of Musescore file conversion. As a first step, the Measure Map extraction doesn't aim at fixing these errors: we explicitly take what we have, without trying to be smart. However, it should be nice to detect that "our measure map has some repeat issues".

Especially, the start/end_repeat must match the next lists. Is it always true that :

• "count": 18, "next": [11, 19] implies that :
  • current measure (18) has "end_repeat": true
  • measure 11 has "start_repeat": true
• "count": 18, "next": [19, 23] implies that there is a second ending