Looking through the MIDI 2.0 specs I’m having a hard time as I’m not really seeing the things I was hoping for. Someone correct me if I’m wrong, but is there still a 16 channel limit and only 128 notes?! Most of what I’m seeing as far as improvements go are things that sound like they’re going to be more difficult to develop for such as crosstalk between devices. Who’s asking for that? I just want to be able to send simple data more efficiently with the lowest amount of latency possible. A big one I was hoping for, but am not seeing is the ability to send individual frequencies. Basically the note number could function as an identity for the note, and the frequency would be part of the data with it. Instead I’m reading about tuning dumps. Something we already have and isn’t as efficient for microtonal and flexible tuning solutions. 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. That’s all I want. Also, I see a major problem with requiring 2.0 devices to be able to receive 32 polyphony. I know of hardly any instruments that do that, especially if we’re talking about analog synths. Even for soft synths, for things like physical modeling when you have only a few notes you start to run into performance issues. That requirement seems completely unnecessary and like it’s hurting developers and making 2.0 much less likely to be used. 2.0 should listen to what MPE is doing and make those things easier.
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.
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.
0
Undo
Votes
A couple of quick points.
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.
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.
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.
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.
THE MIDI ASSOCIATION (TMA)
The community of people who work, play and create with MIDI
The community of people who work, play and create with MIDI
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.
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.
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.
Mike.
Jonathan
set the type of the post as
Suggestion — 1 year ago
- Page :
- 1
There are no replies made for this post yet.
