Add support for MIDI 2.0

[rettinghaus]

Currently all midi specific parts of MusicXML are limited to values that comply with the MIDI 1.0 standard.
MIDI 2.0 extends some of the possible value ranges, e.g.,midi-channel has been extended up to 256 (16x16).

[mscuthbert]

I'd like to hear from implementers about support for MIDI 2.0 standard -- would extending midi-channel here to allow up to 255/256 break their implementation? Or should this be a separate <midi-2-channel> tag?

I think that MusicXML's MIDI implementation should be somewhat conservative and only change settings like midi-channel when there is very strong industry support for it. MIDI 2.0 worked hard to be backwards compatible with MIDI 1.0, so I think that MusicXML's MIDI support should also be. For channel that's not too hard. But when we get to MIDI Velocity, that's very different, since the velocity needs to be downscaled from 16 to 7 bit (and the value of 0 has a different meaning between the two systems).

[infojunkie]

I maintain several MusicXML converters (both import and export) and I'm interested in MIDI 2 support.

To me, the fact that MIDI 2 is backward compatible with MIDI 1 means that it should be possible to update MusicXML's MIDI support such that:

• Existing implementations are not broken
• Only minimal changes to the spec are needed

Starting from this premise, I would try to look at each MIDI element in MusicXML and attempt to upgrade it to MIDI 2, without duplicating existing elements as the first design choice. Of course, I would also expect any MIDI 2 support to not modify any existing MIDI 1 element / data type. It may be inevitable to introduce new elements for MIDI 2, but what I am trying to say is that we could reasonably aim to avoid creating new elements that are MIDI 2 versions of existing MIDI 1 elements (e.g. midi-2-channel for midi-channel). Of course, this requires a good understanding of MIDI 2, which I cannot claim to possess 😄

For example, in the midi-channel case, the way MIDI 2 is compatible with MIDI 1 is that the legacy 16 channels are now part of MIDI 2's default "Channel Group" which is Group 1. There are 16 such Channel Groups, which increases the channel address space to 16x16 = 256. Furthermore, a MIDI 1 channel would be exactly the same for MIDI 2 (assuming the default Group 1).

In this case, introducing a new element for Channel Group might make more sense than a new element for Channel - something like midi-2-channel-group which also accepts midi-16 data type. Existing applications would still process midi-channel correctly and would be upgraded to process midi-2-channel-group to add MIDI 2 compatibility - the absence of which indicates a Channel Group of 1.

As far as I can tell, the following are the MIDI-specific elements:
midi-bank
midi-channel
midi-device
midi-instrument
midi-name
midi-program
midi-unpitched
volume
pan
elevation

A similar study would be needed for each of those to update MusicXML to support MIDI 2 (in addition to exploring needed additions). I'd be happy to be part of a group that focuses on this upgrade as a whole, as opposed to each element separately.

[mdgood]

The <volume>, <pan>, and <elevation> elements are defined independent of MIDI's representation, unlike the elements with midi- at the start of the name. Since they are decimal datatypes, they can already handle MIDI 2's increased precision. I agree with the general approach of trying to design things so a midi- element isn't duplicated with a midi-2- element.

[rettinghaus]

I also think we can extend the midi elements without breaking anything. My original example for midi-channel could get a @group attribute which would allow midi-16 data type values with a default to 1, while keeping the allowed values for the element itself. This way all 256 possible channels within the 16 groups can be represented.