A) You just need to sign up with an email address. The docs are free. If you don't want to do that, you probably know someone who has access.
B) There's a new binary protocol and a new pseduo JSON-rpc framework on top. If you read the free documents you would not come away with this conclusion.
We're a long way removed from sending 7-out-of-8 bit messages along 3 feet of cable with optocouplers doing our decoding. It's like a weekend of work to write a MIDI 2.0 decoder for a massive amount of benefit. And it's transport agnostic.
Midi 1.0 is still in active, since they didn't change the protocol until 2.0
It's hard to see what you want: You can't be complaining about lack of physical interfaces not present on your hardware (the additional specs for Midi over USB, RTPMidi, TRS plugs and the 3.3v 5pin din) so are you sad that your drum machine doesn't play bagpipes when you switch to program #110 (General Midi) or that a Juno 106 doesn't magically add reverb when you crank up controller #91 (the suggestions for CC mappings) or perhaps you are trying to send samples to a Yamaha DX7 using the DLS standard?
You are not really missing out though. I.e. you can still use the broil setting on your toaster oven even if your microwave doesn't support that. no-one is forcing you to use the lowest common denominator on every device.
> Midi 1.0 is still in active, since they didn't change the protocol until 2.0
This is not correct at all. There are tons of active extensions on top of the midi 1.0 protocol, even outside of sysex. It's not like they just wrote it all at once and then left it alone. These are the accretions I am referring to. Examples:
MIDI Time Code (MTC) (MMA-001 / RP-004 / RP-008)
General MIDI System Level 1 (GM1) (MMA-007 / RP-003)
General MIDI 2 1.2 (GM2) (RP-024/RP-036/RP-037/RP-045)
File Reference System Exclusive Message (CA-018)
Sample Dump Size, Rate and Name Extensions (CA-019)
MIDI Tuning Updated Specification (CA-020/CA-021/RP-020)
Controller Destination Setting (CA-022)
Key-Based Instrument Controllers (CA-023)
Global Parameter Control (CA-024)
Master Fine/Coarse Tuning (CA-025)
Modulation Depth Range RPN (CA-026)
Extension 00-01 to File Reference Sysex Message (CA-028)
CC #88 High Resolution Velocity Prefix (CA-031)
Response to Data Inc/Dec Controllers (RP-018)
Sound Controller Defaults (RP-021)
Redefinition of RPN 01/02 (RP-022)
Renaming of CC91 and CC93 (RP-023)
Three Dimensional Sound Controllers (RP-049)
MIDI Polyphonic Expression 1.0 (RP-053)
Perhaps I was unclear: None of those additional specs change the wire protocol - Just like IMAP, HTTP and DNS doesn't change how TCP/IP works. I.e. MTC is a sysex format, General Midi is just instruments names -> program numbers assignments + CC/RPN mappings. The tuning stuff are typically RPN messages. MPE hogs all channels for sending poly-expressions but its all using the basic Midi 1.0 message types
you originally wrote:
> ... Various extensions are only sporadically supported, so in effect you typically don't have any more capability than the simplest version of the protocol anyway.
This is just not true - every device have different capabilities and you control them with what ever midi messages the device responds to. Sometimes they follow those standards and other times the don't.
I.e. I can control the Reverb level on a Yamaha AN1X through CC#91 (which is a General Midi defined controller mapping for Effect 1 level). If I send CC#91 to an Arturia MicroFreak it will change ARP/SEQ rate. Sure it's a little annoying that I have to read the midi implementation list for each of my devices, but I'm not going to give up and never control those settings just because the don't align with the published extensions.
OK, sure, I agree that at some level the wire format has been stable, but that's like saying "http and http/2 both use TCP, so they are the same protocol".
B) There's a new binary protocol and a new pseduo JSON-rpc framework on top. If you read the free documents you would not come away with this conclusion.
We're a long way removed from sending 7-out-of-8 bit messages along 3 feet of cable with optocouplers doing our decoding. It's like a weekend of work to write a MIDI 2.0 decoder for a massive amount of benefit. And it's transport agnostic.