api: time signature improvements

[rpatters1]

The api should permit multiple time sigs per part, similar to what it does now for key signatures. And each time signature should support multiple beats/beat-type pairs per time signature.

This is a breaking change, so I won't submit a PR without feedback, but I want track it.

[rpatters1]

I think we need a timesig component of beats/beattype and then an array of those in TimeSignatureData.

[webern]

Multiple-per-part, sounds, on the surface, pretty simple if we already have a precedent to follow.

The second part, multiple beats/beat-type pairs, is a little less obvious how to handle, especially since it is only one of probably a nearly infinite number of special cases that MusicXML tries to accommodate. Do you have examples of XML you want to create? I wonder if they already exist in skipped test corpus files or if we should add test corpus files that do what you want (ideally stripped down to the time signature representations). For example a file with few or no notes and few other things, but just the sorts of time signatures that you want to represent.

I want to be careful with complexity so I'd like to think it through. In general, I feel that by attempting to support every possible engraving or semantic possibility, specs and/or APIs can become extremely difficult to understand.

One possibility that comes to mind would be to design our first "raw MusicXML" hook, so that if your time signature is just 4/4, then you don't have to deal with any complexity, but if not, then you get access to a builder to do whatever the MusicXML spec allows.

Just thinking out loud here at the moment.

[rpatters1]

I posted this on the wrong issue:

The musicxml spec supports it in a manner similar to key sigs, using a staff index attribute. (According to codex.)

As for the composite beats/beat-type, here is an example emitted by Finale for one of my more pathological test cases.

        <time>
          <beats>1 + 2.5</beats>
          <beat-type>2 + 4</beat-type>
          <beats>3 + 2</beats>
          <beat-type>16</beat-type>
          <beats>1.5 + 5</beats>
          <beat-type>8 + 16</beat-type>
        </time>

As long as beats and beatType are strings, that will be simple enough to emit. My dom for Finale files already splits them out exactly like this. I just think instead of raw beat/beatypes, there should be a class containing those values and TimeSignatureData contains an array of them. Something like

class TimeSignatureComponent
{
public:
   // the top number of the time signature, e.g. "5" in a "5/4" or "3+2" in a "(3+2)/8"
    std::string beats;

    // the bottom number of the time signature, e.g. "4" in a "5/4"
    std::string beatType;
}

Then TimeSignatureData has std::vector<TimeSignatureComponent> instead of raw beats and beatType. We could add helper setter/getter functions for simple cases, if you wish, but that seems straightforward as-is.

[rpatters1]

The equivalent class in my Finale file dom (musxdom) provides a helper function to return the whole thing simplified to a single N/D time signature. That might be overkill here, but what would be helpful is a setter function something like this:

void TimeSignatureData::setSimple(const std::string& beats, const std::string& beatType)
{
    components.clear();
    components.push_back({beats, beatType});
}

[rpatters1]

Here is the exported test file:

timesigs_composite-ref.musicxml.txt