Support compound time signatures containing shared denominators

[adrianholovaty]

The original draft spec noted the following:

Shared denominators are all-or-nothing. So there’s currently no way to share a denominator for only some of a time signature’s fractions, which would require a grouping construct like 2/4+(2+3/8) or such.

Just making an issue for this to keep track of it. See the time signatures docs for context.

[adrianholovaty]

In commit 41a932b2, we changed the encoding of time signatures to remove the microsyntax and split the data into two values, "count" and "unit". See updated docs here.

We briefly chatted about compound time signatures in today's cochair meeting. Here's a quick braindump of initial thoughts:

Given many notation apps don't support compound time signatures, we should endeavor to always define a base time signature as a simple fraction. Compound time signatures should be treated as "progressive enhancement" (to borrow a term from web development). That is, applications that support compound time signatures can get all the information they need, but applications that don't support them can still get a meaningful timesig value that makes sense in a more limited context.

One approach could be to use a separate JSON key for the fractional time signature data. For the fractional time signature "(2+2+3)/ 8", perhaps it could be encoded like this:

{
  "count": 7,
  "unit": 8,
  "fractions": [
    {"value": [2, 8]},
    {"value": [2, 8], "additive": true},
    {"value": [3, 8], "additive": true}
  ]
}

Obviously there's a lot of possible complexity in compound time signatures, so there's a lot of detail to work out. But I think that could be the general shape of it. We'd always require "count" and "unit" as a baseline, then provide a key such as "fractions" to hold the richer compound data.