Multiple Time Signatures, Note-valued Time Signatures

[rpatters1]

Has the collected wisdom considered multiple time signatures per measure, where a time signature is expressed as a composite of two time signatures, e.g. 2/4+3/8. Or when two equal time signatures occur simultaneously, as in 2/4(6/8)? I'm wondering if global.measure.time shouldn't be an array of times.

Also, many scores do not use a number for the bottom. Instead they use a note value. I wonder if we shouldn't use a note value object for the unit rather than a 1-off numerical enum.

[adrianholovaty]

I recall briefly discussing this a while ago with my fellow cochairs, and the idea we had was as follows:

• global.measure.time remains a simple fraction
• global.measure gains a more complicated (optional) data structure that supports lists of time signatures and visibility options

This approach is motivated by the following philosophies/observations:

• A lot of software doesn't support compound time signatures, so we want to provide a "lowest common denominator" solution with an optional "proper" solution for software that can indeed use the data.
• We don't want to complicate the common case (e.g., by always using an array for global.measure.time) simply for the benefit of more obscure notational situations.
• Every time signature can indeed be expressed as a simple fraction, even crazy compound ones. It's generally useful for software to have the time signature expressed as a simple fraction, even if that's not actually displayed in the notation.

[mscuthbert]

That fits my recollection and what we decided as a general philosophy: if something has both a common/naive representation and a precise/rare representation: support both but require those implementing the rare representation to also provide a common representation fallback (but not vice-versa)

[rpatters1]

I don't have any issue with the simple fraction, and that is probably enough for playback use cases. However, I have been under the impression that MNX is primarily aimed at notation. If that's so, the simple fraction is losing a lot of semantics.

[adrianholovaty]

@rpatters1 I agree, and that's why we plan to support a way of encoding the more complicated case. We just haven't done it yet! Feel free to make a specific proposal here.

[rpatters1]

I will tell you what Finale does, with some comments on how some of it might be implemented in MNX.

For the simple case, instead of a simple number, it uses note values for the bottom number. So the simple a case allows a distinction between 2 dotted quarters and 6 eighths. However, since there is no visual distinction (they both show 6/8) perhaps this is not necessary.

What the distinction does control is how the notes beam automatically. Even the simple case needs to have some way to indicate automatic beaming. Perhaps this could be solved by adding an optional beatValues property to the time object that is an array of note values.

For the compound case. Finale supports arrays of times signatures, each potentially comprised of multiple numbers on top and multiple numbers on the bottom. Personally, I think this is overkill and does not really have a use case.

Finally, Finale allows an actual time signature and a different time signature for display. Perhaps MNX could use something along these lines as well.

To summarize, the time object would add

beatValues: an optional array of note values that determines the beats (and could be used for automatic beaming). A single value in this array would be repeated throughout the measure. In the case of multiple values, they would have to add up to the length of the measure.

Perhaps the new array in global measure (and ultimately potentially in staves) could be called displayTimes.

time: required. This would be the same class as the global measure time object.
unitNoteValue: optional note value to display as the unit, rather than time.unit.
isAlternate: optional boolean (default false) that specifies that this is an alternate interpretation of the time signature. If false, it is additive. All members of the array would have to be one or the other. (This feature needs some more thought.)

[rpatters1]

One futher reflection, I think embedding a time instance in displayTime might not make sense. Instead of time it should perhaps be:

counts: a required array of at least one number.
unit: required value same as time.unit.

Then unitNoteValue as above and isAlternate however we figure out how to do it. Display time signatures have no need for a beatValues array.

[rpatters1]

Actually, I think one of either displayTime.unit or displayTime.unitNoteValue should be required and the other omitted.

So to summarize my (edited) proposal for displayTime:

counts: required array of numbers containing at least one element.
unit: optional value the same as time.unit.
unitNoteValue: optional note value to display as the unit, rather than unit.

It must contain either unit or unitNoteValue but not both.

isAlternate: optional boolean (default false) that specifies that this is an alternate interpretation of the time signature. If false, it is additive. All members of the array would have to be one or the other. (This feature needs to be worked out.)