No, I want there to be only one way to do something in the protocol and to remove arbitrary binary exchange, this is one pain point. It turns your "standard" into a Frankenstein's Monster of data exchange, and you'd think we'd have learned over the last few decades that ambiguity in specification of a communication protocol is just going to lead to headaches and incompatible/buggy hardware.
It's also weird to say SysEx is needed for backwards compat with MIDI 1.0. You can just require a translation layer between MIDI 1.0 sysex and MIDI 2.0 configuration/property exchange for backwards compat. Opaque binary as a part of the protocol does not encourage compatibility among hardware.
The MIDI spec was successful for 30+ years for a reason and manufacturers managed with SysEx without any issue, there is no justification for any "compatibility layer" whatsoever here. The problem wasn't the spec obviously.
As a musician and software developer I'd disagree. Sure, manufacturers are getting on fine because they can do whatever they want, but it makes the setup for anyone who isn't the manufacturer much more bespoke and challenging, as others have said in thread.
Leaded gasoline was successful for decades too, but there comes a time to take things to the next level.
> As a musician and software developer I'd disagree. Sure, manufacturers are getting on fine because they can do whatever they want, but it makes the setup for anyone who isn't the manufacturer much more bespoke and challenging, as others have said in thread.
MIDI 1.0 was successful for 30+ years because of its simplicity, so I'm not sure what you are disagreeing with. Building a MIDI payload is extremely simple and serious manufacturers will document their MIDI implementation in public documents.
What part of the MIDI spec did you have hard time with when developing software using the MIDI 1.0 protocol?
Your comment about gasoline has absolutely nothing to do with MIDI.
Allocating memory (by asking the OS) in a realtime context is a no-no. This means guessing the maximum size of a sysex ahead of time or breaking RT programming rules.
The other tricky issue is the way MIDI 1.0 defines the transmission of the LSB and MSB for 14 bit messages. They got it backwards, requiring the receiver to use a timer. Might have been sensible for baked-in-h/w MIDI gear, not so great for general purpose computing.
It's also weird to say SysEx is needed for backwards compat with MIDI 1.0. You can just require a translation layer between MIDI 1.0 sysex and MIDI 2.0 configuration/property exchange for backwards compat. Opaque binary as a part of the protocol does not encourage compatibility among hardware.