Open pythouille opened 1 year ago
The following displayed measure must mention its
count
count
is not musical. The user may want to rather specify its number
.
There should be an exception to the default values of #2:
name
: idem
If a measure is fully specified with a name
of 19a
, the next one (when compressed / not specified) should have a name
of 20a
. Of course it's difficult to imagine all possible cases, but at least handle these number+letter cases.
The most common cases I found are 19a
followed by 19b
, for second endings that were 1-measure long (in Mozart sonatas). After 19b
, it is back to 20 and so on. The compressed measure map [1, 19a, 19b, 40]
(default without number) would thus be [1, 19a, 19b, 20, 40]
(the default you propose), a bit longer.
But yes, in the general case, your proposition is better for longer second endings or 'unfolded' repeated parts. I update it.
count
is not musical. The user may want to rather specify itsnumber
.
Very good point.
Update: I have implemented the creation of the "default successor" as part of this PR. Specifically, this happens in the function make_default_successor()
in the relevant diff).
Based on this I have added a prototype of a compression algorithm that only omits measures that have successfully been created from their predecessor (30d5491).
What are the specification for compressed / uncompressed? The aim is to keep only necessary information without any loss of information.
number
so that we can deduce how many measures were skipped this way.Remarks/questions:
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?[{'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 answercount
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 leastcount
orid
: should we reconsider this, or allow compressed versions only to break the rule? (or add counts to compressed!)