The kind of features you are looking for are in the M2-104-UM UMP and MIDI 2.0 Protocol Specification. You will find a new data format with 16 Group addresses, each with 16 MIDI channels (total 256) and System messages. Controller values are 32 bits. There are optional timestamps for higher timing accuracy. New Per-Note Controllers. You can optionally put a precise pitch into a Note On. There are several other new mechanisms for expressing and controlling precise pitch. There is a huge space for expanded functionality and new messages.

Mike.

Hi Jonathan,
Essentially you're quite correct, in that there are still 16 channels per port, just the same as in MIDI 1.0.
But, as in MIDI 1, it's quite possible to have multiple ports, so expanding the total number of channels to as many as are needed to represent e.g. a full orchestra.

So, using an orchestral VSTi, I tend to map the woodwind section to the first port, brass to the second, strings to a third and other instruments (e.g. timpani, piano, etc.) to a fourth.
So I end up typically using up to 64 total channels.

The number of notes is still set at 128 just as before.
A missed opportunity in my view too.

Latency is, in most cases, more a function of how efficiently the MIDI data is turned into audio data, less that of note latency due to MIDI transmission.
But there is little that can be done to improve MIDI note latency given that the physical interface is serial.
With USB and most modern protocols it is packet based and therefore subject to jitter due to the way a polled protocol works.
The packet then has to processed and that's a serial decoding process.

Frankly, I don't see where any improvement over the way micro tuning works has been improved.
And ... honestly, how many users need 32 bit controllers, or even 16 bit? As many as 0.01% of MIDI users?

And we still, 2 years after the protocol specs came out, don't have a MIDI 2 SMF spec.

JohnG.

A couple of quick points.

The number of notes is still set at 128 just as before.
A missed opportunity in my view too.

Really, someone please tell me they’ve expanded the number of available notes (not talking about polyphony, but expanding beyond 128 for microtonal scales) and channels

Groups are actually not the same as Ports. A MIDI Endpoint can have 16 Groups with 16 Channels and each Channel has 128 notes. Each Note can have Per Note Pitch Bend and direct control of Pitch in the Note On. Doing the math says that is 124928 possible Notes with unique pitch properties. Ways to "Group Groups" into functional blocks that have more than 16 Channels will be included in the updates to the core MIDI 2.0 specs we are releasing soon. We already know that all the Plug In formats (VST3 , AU, CLAP , etc.) support this kind of Per Note Pitch Control.

Latency is, in most cases, more a function of how efficiently the MIDI data is turned into audio data, less that of note latency due to MIDI transmission.
But there is little that can be done to improve MIDI note latency given that the physical interface is serial.
With USB and most modern protocols it is packet based and therefore subject to jitter due to the way a polled protocol works.
The packet then has to processed and that's a serial decoding process.

The MIDI 2.0 specification includes Jitter Reduction Time Stamps which can be used to reduce Jitter on Universal MIDI Packet transports like USB MIDI 2.0 for both MIDI 1.0 and MIDI 2.0 Voice Channel Messages. There is also improvements in timing in the USB MIDI 2.0 specification. This is pretty low level stuff so it is much more of interest to the people developing USB MIDI 2.0 drivers and the operating systems than to end users.

And we still, 2 years after the protocol specs came out, don't have a MIDI 2 SMF spec.

John, that's a good point. We have been working since 2020 on prototyping MIDI 2.0 and also major updates to all the core MIDI 2.0 specifications. We are sending nine MIDI 2.0 specification updates to our MIDI Association members for 30 day review. A number specs have already been sent to our members.
One of the specifications that will go out soon is a new SMF2 MIDI Clip File Format which has been completed.

We are planning on a number of articles about these new updates that will be available before the Audio Developers Conference in November including an explanation of the basic design of the SMF2 MIDI Clip file.

Was there any traction already in regards of the SMF2 file format? Maybe a first draft spec that could be integrated into Software Systems to provide early feedback?
Maybe a first very basic SMF2 based on a modernized SMF1 could be defined to have at least something in the market that could be extended later on?

My current approach is to simply pack Midi 2.0 Events into a SMF1-Type 0 file and it works out fine for my use cases. But obviously those files are not interopable with any other software.