Should global (system) notations be interspersed within regular parts?

[joeberkovitz]

Instead of placing within <measure> elements within <global>, should system notations be placed in individual parts and tagged in some way, perhaps via a scope="global" attribute or something similar?

This would avoid the problem of the <global> or similar element being very sparse with most measures containing nothing.

However, this approach could scatter system notations throughout the score in a happenstance way, since there is no particular part that makes sense for them to belong to.

While they could be forced to be placed in the first part, this leads to ambiguities as sometimes the first part is not visible on all systems. In MusicXML, the result is that system notations tend to appear in the topmost visible part, which varies unpredictably from score to score.

[clnoel]

If this is truly a concern, I say we specify an optional(?) "max-measure-index" attribute as a courtesy to consuming implementations. For our current attempt to pin down the "standard" profile, we only need this attribute at the global level, since all parts are guaranteed to have the same number of measures, but eventually we'll need it at the part level to override for when we are allowing un-aligned measures.

I think that the advantage in reading and writing of being able to skip measures where nothing is happening overrides the concern about the max measure number.

[joeberkovitz]

I think the idea of providing a maximum is a very useful direction. I'd just prefer to see it required, rather than optional. This particular spec editor has a strong bias against courtesies -- having learned from experience that it leads straight back to the unpredictability that we're all trying to purge.

It could go right into <global>, as you say. (I'm not sure it would be needed elsewhere, even in the multi-metric case, because one has <global>s there too.

[clnoel]

OK, then required number. But, now that I'm thinking more, it should be measure count, not max index number (unless we are restricting the index numbers so that they start at 1 and never skip, so that some part has to reference each index number). And we should be specific as to whether "pick-up measures" count as a measure.

[joeberkovitz]

Good points. To clarify:

index is 1-based, so "count" and "maximum" are the same. And yes, "count" is the clearer term!

Pick-up measures absolutely do count in this sequence, because we're being clear that this has nothing to do with the user-visible numbering of measures (see PR #81 for the detailed language).

[cschardt]

Measures:

1. Measures have to be counted regardless of any musical meaning and numbering (pick-up, repeated numbering in first/second ending und whatnot) to keep clearity. They simply should count the xml-entities, shouldn't they?
2. Question: How should sequences with polymetric parts be handled? Assume a piece starting with 3 measures in staff 1 against 2 measures in staff 2, after this continuing with common measures:

   Staff 1:  |   1    |    2    |    3    |    4    |   5   | ...
   Staff 2:  |      1      |       2      |    4    |   5   | ...

   I never had to do with such compositions but I think, that this is the only resonable way of counting.

[mscuthbert]

Another possible way of counting could be

Staff 1:  |   1    |    3    |    5    |    6    |   7   | ...
Staff 2:  |      2      |       4      |    6    |   7   | ...

or even:

Staff 1:  |   1    |    2    |    3    |    4    |   5   | ...
Staff 2:  |      6      |       7      |    4    |   5   | ...

in either case, giving unique indexes for each measure item that has individual properties.

[joeberkovitz]

@cschardt That's exactly the proposed scheme in #81.

[joeberkovitz]

@mscuthbert These alternatives are feasible, but seem overcomplicated. The "namespace" for counting measures is only the set of global and part elements that share the same structure. Starting at 1 and counting up is easy and it works, since there cannot be collisions between measures in disjoint structures.

[mscuthbert]

@joeberkovitz gotcha -- does this mean that if there's one case of non-aligned measures in a part that the part must have its own separate set of <measure> elements for the rest of the piece?

[joeberkovitz]

@mscuthbert I think so... but an example would be good to make sure. There might be a case for allowing a part to elide some measures from its layout without changing the overall structure. If so then I would suggest it's a different issue.

[joeberkovitz]

Here's another alternative to throw out about the guess-the-score-length problem: require a <global> element to always encode the last measure in its content. If the last measure is empty, that forces the inclusion of an empty element <measure index="SCORE_LENGTH"/>.

[clnoel]

I could be mistaken, @joeberkovitz , but I believe that your newest suggestion might be harder to validate, and otherwise be functionally equivalent to adding a measure-count attribute.

[bhamblok]

You could call me tenacious, but ... :-) This again wouldn't be of any issue if we choose for a more timewise structure (as discussed above).

[joeberkovitz]

Chairs: today we decided to remove the sparse-encoding feature from this issue as this facet of the change was generating too much controversy and needs further thought, so fixing it here was overstepping. Note that #52 already tracks that issue.