"Multiple voices" is another problematic example

[rpatters1]

The Multiple voices example is another example that depends on some close-to-magical functionality from the importer. The json contains absolutely no hint as to which voice should have stems up and which should have stems down.

In the general case, correctly inferring stem directions from multiple sequences seems non-trivial. It is surprising to me that the committee would assume that level of sophistication in a consumer when they contemplate consumers that don't even know whether to show accidentals in C major. The only solution I can think of involves sloughing through all the sequences just to put them in some kind of average staff height order before even beginning to process them, taking into account cross staffing somehow. That's a lot of extra code that every importer has to write and a lot of opportunity to be wrong.

The two programs I am most familiar with, MuseScore and Finale, do not attempt it. MuseScore hard-codes stem directions up/down for even/odd voices (counting from 0). And Finale has per-layer settings that determine it. I don't know about Sibelius or Dorico, but I suspect at least one of them takes a similar approach. For these programs, it would be trivial for them to export hints about stem direction.

Here are some hint ideas:

• Add a dictionary of voices that include default stem direction per voice. Then suggest that multi-sequence staves should use those voices. (I already proposed this in Managing flexibility for imports and exports. #468, but I add it here for completeness.)
• Suggest a consistent order for sequences in a part measure. Maybe we could suggest that sequences should be interleaved up/down/up/down, or vice versa.
• Add an optional stem direction to the sequence itself, and suggest that it should be used when more than one sequence is present for the same staff.

I realize that we are already handling a lot of this with layouts. Layouts may certainly override these hints. But most of the examples contain no layouts. I would like to be able to import them as closely to how they appear in the documentation as possible. Right now, this is a big sticking point.

[mscuthbert]

My feeling is that there needs to be default-type settings that can apply at the score/section/part/staff/sequence levels -- so that any of them can specify things like stem direction (some percussion staves and medieval transcriptions use exclusively stem up), note size, color, etc. So stem-direction is only one of many things to keep track of.

[rpatters1]

The concern I have is finding the right tradeoff between flexibility and complexity. We can have flexibility, but then we need to define precedence and best practice. When you sit down to really do that, sometimes the flexibility isn't worth it.

Meanwhile, we are faced with the problem that anything that can be done two ways is done two ways. We have the linked example that lists voices lower-then-upper, but at least two music programs (MuseScore and Finale in its default configuration) that list voices upper-then-lower.

Somehow this needs to be addressed without adding complexity, even if it is just a recommendation in the docs. I don't know musicxml well enough to know if it addresses this. If so, maybe we should explicitly follow its convention.

[rpatters1]

I just had another idea. We can leave stem direction out of it. Currently that is controlled by events and layouts. The semantic question I have been struggling with is whether the sequence represents an upper voice or a lower voice, not the stem direction per se. The default behavior for that is to put stems up for upper and stems down for lower, but that could indeed be left up to the consuming software.

So another idea is to recommend (or require) sequences for multiple voices on the same part staff to specify if they are upper or lower voices. Personally, I believe I prefer this to any I have suggested so far. I truly captures a semantic aspect that is missing, and mnx is all about capturing musical semantics.