Support scores without measures

[cecilios]

Current "Secuence content" procedure has to be adapted for measure-free scores, that is for scores without time signature, consisting of a single big measure. In particular:

• Step 3.3.1.2: Set sequence cursor to the end of the measure as defined by its time signature. [This case is probably irrelevant as it is not expected to find an event lasting the whole score duration; anyway the procedure should say something for dealing with this.]

• Step 8: If sequence cursor exceeds the specified duration for the enclosing element (time signature for a measure), throw a processing error. [For measure-free scores, better ignore this check]

[joeberkovitz]

The current proposal assumes that even for scores consisting of a single big measure, the total duration of that measure should still be present in a <time> element (this seems like a reasonable condition of CWMN). The time signature may not be shown -- any element can be hidden using a display: none style -- but there is still a definite duration to the score.

Note that parts with different durations should be covered by new issue #55.

[cecilios]

If <time> element is mandatory then its signature attribute should be optional or better, define a time signature value for these cases, meaning 'no time signature'. It would be a bad idea to encode a real time signature value such as 4/4 and use a display: none style as this will not capture the semantics and will force to analyse the style attributes to get the meaning. Moreover, the hidden time signature value would be applicable in places were it is expected, such as in the "Sequence content" procedure and would provide erroneous values.

[cecilios]

A possible drawback of making <time> element mandatory would be for score edition, for notation editors not based on predefining a certain number of empty measures, but that operate in a similar way as we do with paper and pencil: a long staff to write on it.

In these cases, while the user does not enter a time signature it would be painful to try to pre-define the duration of the score and to having to update the <time> element every time the user enters a new event. This would be contrary to the objective of facilitating DOM interaction for simple editions.

Also it would be against the principle of avoiding to explicitly encode derived data: IMO a signature value = 'no time signature' would automatically imply that the score duration is the duration implied by the events it contains. Also taking into account that the total score duration provided by the <time> element is of interest only for the "Sequence content" procedure, value = 'no time signature' would be useful for fixing the procedure.

[clnoel]

@cecilios I would like to tie in the conversation we are having about barlines in #69 to this conversation as well. @joeberkovitz made a good point about measure-ending barlines being the places where reflowed scores are allowed to have system breaks.

From that standpoint, should we insist that each system in a score without measures be a "measure" with it's ending barline set to "none"? Or should we allow an encoder to place invisible breaking barline elements in a single measure of content that would also be a natural encoding for this kind of score?

[cecilios]

@clnoel For scores without measures the idea of using measures and hidden barlines for defining system breakpoints is contrary to the free-flow layout goal. Current behaviour of some existing applications should not guide the definition of a new standard.

[joeberkovitz]

@cecilios As a point of process, we definitely do need to think about the current behavior of existing applications. We must strike a balance between using existing models (which risks "freezing" undesirable concepts into the spec) and inventing new ones (which risks adding new implementation burdens that vendors don't want). I am not saying that we always keep the old or always embrace the new, just that there is an inherent tradeoff that needs to be considered.

[cecilios]

@joeberkovitz I fully agree that we must strike a balance between using existing models and improving the standard. But this does not imply to blindly preserve everything without trying to find alternatives. Probably, current behaviour can be preserved without the need to impose awkward constructions on the standard. For instance (just a first quick though, not a proposal):

• introduce a new element for suggesting feasible breakpoints in the events flow, e.g., a new element similar to a hidden barline but without implying it is a barline and without tricks -- hidden style -- for making it invisible in layout. This new element could be freely used not only on scores without measures but in any other score. It will provide clues about feasible break points, to facilitate layout when convenient. This element can also be of use in any other scenario.

• current scores without measures, modelled in MusicXML as measures without barline to facilitate breaking the score into systems, can be easily converted: just one measure for the whole score, with old measures replaced by marker elements (the above proposed elements).

Conversion from MusicXML to this format should be simple and would preserve backwards compatibility, and the new MNX standard will be cleaner. In any case, I feel that there is an obligation to push forwards the technology and not just freeze everything due to software designed 30 years ago. Word processors do not need a word wrapper in order to split the text into words and to break lines. Layout algorithms in existing applications should evolve and be improved, they need more intelligence and not to base system breaks just on measures. Take also into account that future MNX producer apps. oriented to free-flow displays could behave in a way that will make more difficult importing the scores they create from old paper-oriented applications: for instance, they could not include the 'feasible breakpoint clue' element (it can not be mandatory) or, if required by the MNX standard, will include fake measures that are not appropriate for consumer apps. oriented to layout the score to be printed on standard paper sizes. So, or they improve their algorithms or will fail importing these scores as they will need reflow.

Probably this issue is related to #57 and #13 (what assumptions does MNX so that layout algorithms can work properly?)

Anyway, the chairs should proceed as they consider better.

[joeberkovitz]

Thanks for the thoughtful proposal. It will be good to get some feedback from implementors on this point. It may get more attention by putting it into #57 since it is not snippet specific.