Hello MIDI community!
Bit of a disclaimer at first: I'm not much of a techie when it comes to MIDI so please consider the latter when replying to me.
I'm currently going through the MIDI 2.0 specs in order to get a bit of a grasp of what's coming up, and while reading the document on the UMP there's something I don't understand: the specs seem to stress that the UMP scheme is compatible with MIDI 1.0 as well, but how will legacy devices respond to received UMP messages? Will they just automatically discard all the extra bit of information (like Group number, JRT, etc) and extract the MIDI 1.0 message bit out of it?
[Another related question is, will this grouping of MIDI channels be somewhat usable with legacy devices only to allow more than 16 of them to be interconnected without channel conflict, and if so how is that being done in practice?] EDIT: I have just found out about this one. All MIDI 1.0 devices will have to be grouped together and treated as such (p.16 of the document). So in practice there will not be a way of having more than 16 of them connected together without at least a MIDI 2.0 "hub" separating them into more than one group.
Thanks for clearing that out for me!
Bit of a disclaimer at first: I'm not much of a techie when it comes to MIDI so please consider the latter when replying to me.
I'm currently going through the MIDI 2.0 specs in order to get a bit of a grasp of what's coming up, and while reading the document on the UMP there's something I don't understand: the specs seem to stress that the UMP scheme is compatible with MIDI 1.0 as well, but how will legacy devices respond to received UMP messages? Will they just automatically discard all the extra bit of information (like Group number, JRT, etc) and extract the MIDI 1.0 message bit out of it?
[Another related question is, will this grouping of MIDI channels be somewhat usable with legacy devices only to allow more than 16 of them to be interconnected without channel conflict, and if so how is that being done in practice?] EDIT: I have just found out about this one. All MIDI 1.0 devices will have to be grouped together and treated as such (p.16 of the document). So in practice there will not be a way of having more than 16 of them connected together without at least a MIDI 2.0 "hub" separating them into more than one group.
Thanks for clearing that out for me!
Accepted Answer
0
Undo
Votes
Hi,
Please see our reply. We are working on some more materials to help explain all the possibilities with MIDI 2.0.
Actually legacy devices will never receive UMP messages. If you plug in 5 PIN, there is no UMP, just serial MIDI. If you connect a legacy USB-MIDI 1.0 device, the USB-MIDI 1.0 driver will be loaded. The only time the USB-MIDI 2 driver will be loaded is when a MIDI 2.0 device that supports UMP is connected. These details that are being worked out in the USB-IF now.
The UMP packet has 16 Groups of MIDI. Each Group has 16 channels. It's easiest to think of each of these Groups as separate virtual MIDI cables. Each Group can include either MIDI 1.0 Channel Voice Messages (CVM) or MIDI 2.0 Channel Voice Messages (CVM). You can't mix MIDI 1.0 CVM and MIDI 2.0 CVM inside of a Group/Port.
When a UMP Group contains MIDI 1.0 data, a translator would extract the extra data and send the basic MIDI 1.0 data to a legacy device. When a UMP Group contains MIDI 2.0 data, then the same would happen but with the added step of translating MIDI 2.0 channel voice messages to the MIDI 1.0 equivalents.
The MIDI 2.0 protocol specification defines exactly how to translate between MIDI 1.0 CVM and MIDI 2.0 CVM in both directions.
The extra bits of information are more than just the Group number or JRT. There is also the added resolution of the 32 bit data.
Most of that translation will happen automatically in the OS and some of it will happen when you plug-in a new USB device (which class compliant MIDI driver to load will be automatically selected).
But here is the most important part, most users will not need to BUY a new piece of software or hardware to translate between devices with MIDI 2.0 CVM and MIDI 1.0 CVM messages. It will be handled at the OS and driver level and should be completely transparent to end users.
Please see our reply. We are working on some more materials to help explain all the possibilities with MIDI 2.0.
"the specs seem to stress that the UMP scheme is compatible with MIDI 1.0 as well, but how will legacy devices respond to received UMP messages? Will they just automatically discard all the extra bit of information (like Group number, JRT, etc) and extract the MIDI 1.0 message bit out of it?"
Actually legacy devices will never receive UMP messages. If you plug in 5 PIN, there is no UMP, just serial MIDI. If you connect a legacy USB-MIDI 1.0 device, the USB-MIDI 1.0 driver will be loaded. The only time the USB-MIDI 2 driver will be loaded is when a MIDI 2.0 device that supports UMP is connected. These details that are being worked out in the USB-IF now.
The UMP packet has 16 Groups of MIDI. Each Group has 16 channels. It's easiest to think of each of these Groups as separate virtual MIDI cables. Each Group can include either MIDI 1.0 Channel Voice Messages (CVM) or MIDI 2.0 Channel Voice Messages (CVM). You can't mix MIDI 1.0 CVM and MIDI 2.0 CVM inside of a Group/Port.
When a UMP Group contains MIDI 1.0 data, a translator would extract the extra data and send the basic MIDI 1.0 data to a legacy device. When a UMP Group contains MIDI 2.0 data, then the same would happen but with the added step of translating MIDI 2.0 channel voice messages to the MIDI 1.0 equivalents.
The MIDI 2.0 protocol specification defines exactly how to translate between MIDI 1.0 CVM and MIDI 2.0 CVM in both directions.
"Will they just automatically discard all the extra bit of information (like Group number, JRT, etc) and extract the MIDI 1.0 message bit out of it?"
The extra bits of information are more than just the Group number or JRT. There is also the added resolution of the 32 bit data.
Most of that translation will happen automatically in the OS and some of it will happen when you plug-in a new USB device (which class compliant MIDI driver to load will be automatically selected).
But here is the most important part, most users will not need to BUY a new piece of software or hardware to translate between devices with MIDI 2.0 CVM and MIDI 1.0 CVM messages. It will be handled at the OS and driver level and should be completely transparent to end users.
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
0
Undo
Votes
how will legacy devices respond to received UMP messages?
Legacy MIDI devices will not respond to UMP messages. You will need a translator either in software or hardware (like the BomeBox) to sit between the software or hardware device sending UMP messages and the legacy MIDI device.
Accepted Answer
0
Undo
Votes
Hi,
Please see our reply. We are working on some more materials to help explain all the possibilities with MIDI 2.0.
Actually legacy devices will never receive UMP messages. If you plug in 5 PIN, there is no UMP, just serial MIDI. If you connect a legacy USB-MIDI 1.0 device, the USB-MIDI 1.0 driver will be loaded. The only time the USB-MIDI 2 driver will be loaded is when a MIDI 2.0 device that supports UMP is connected. These details that are being worked out in the USB-IF now.
The UMP packet has 16 Groups of MIDI. Each Group has 16 channels. It's easiest to think of each of these Groups as separate virtual MIDI cables. Each Group can include either MIDI 1.0 Channel Voice Messages (CVM) or MIDI 2.0 Channel Voice Messages (CVM). You can't mix MIDI 1.0 CVM and MIDI 2.0 CVM inside of a Group/Port.
When a UMP Group contains MIDI 1.0 data, a translator would extract the extra data and send the basic MIDI 1.0 data to a legacy device. When a UMP Group contains MIDI 2.0 data, then the same would happen but with the added step of translating MIDI 2.0 channel voice messages to the MIDI 1.0 equivalents.
The MIDI 2.0 protocol specification defines exactly how to translate between MIDI 1.0 CVM and MIDI 2.0 CVM in both directions.
The extra bits of information are more than just the Group number or JRT. There is also the added resolution of the 32 bit data.
Most of that translation will happen automatically in the OS and some of it will happen when you plug-in a new USB device (which class compliant MIDI driver to load will be automatically selected).
But here is the most important part, most users will not need to BUY a new piece of software or hardware to translate between devices with MIDI 2.0 CVM and MIDI 1.0 CVM messages. It will be handled at the OS and driver level and should be completely transparent to end users.
Please see our reply. We are working on some more materials to help explain all the possibilities with MIDI 2.0.
"the specs seem to stress that the UMP scheme is compatible with MIDI 1.0 as well, but how will legacy devices respond to received UMP messages? Will they just automatically discard all the extra bit of information (like Group number, JRT, etc) and extract the MIDI 1.0 message bit out of it?"
Actually legacy devices will never receive UMP messages. If you plug in 5 PIN, there is no UMP, just serial MIDI. If you connect a legacy USB-MIDI 1.0 device, the USB-MIDI 1.0 driver will be loaded. The only time the USB-MIDI 2 driver will be loaded is when a MIDI 2.0 device that supports UMP is connected. These details that are being worked out in the USB-IF now.
The UMP packet has 16 Groups of MIDI. Each Group has 16 channels. It's easiest to think of each of these Groups as separate virtual MIDI cables. Each Group can include either MIDI 1.0 Channel Voice Messages (CVM) or MIDI 2.0 Channel Voice Messages (CVM). You can't mix MIDI 1.0 CVM and MIDI 2.0 CVM inside of a Group/Port.
When a UMP Group contains MIDI 1.0 data, a translator would extract the extra data and send the basic MIDI 1.0 data to a legacy device. When a UMP Group contains MIDI 2.0 data, then the same would happen but with the added step of translating MIDI 2.0 channel voice messages to the MIDI 1.0 equivalents.
The MIDI 2.0 protocol specification defines exactly how to translate between MIDI 1.0 CVM and MIDI 2.0 CVM in both directions.
"Will they just automatically discard all the extra bit of information (like Group number, JRT, etc) and extract the MIDI 1.0 message bit out of it?"
The extra bits of information are more than just the Group number or JRT. There is also the added resolution of the 32 bit data.
Most of that translation will happen automatically in the OS and some of it will happen when you plug-in a new USB device (which class compliant MIDI driver to load will be automatically selected).
But here is the most important part, most users will not need to BUY a new piece of software or hardware to translate between devices with MIDI 2.0 CVM and MIDI 1.0 CVM messages. It will be handled at the OS and driver level and should be completely transparent to end users.
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
If you look at CoreMIDI specs on developer.apple.com, you will see a number of functions whose names end with “WithProtocol”. You apparently specify the implementation (1.0 or 2.0) when add a source, destination, or port. The CoreMIDI package will translate when going between protocols. I’m currently on my phone and will add references when I get home.
If you look at CoreMIDI specs on developer.apple.com, you will see a number of functions whose names end with “WithProtocol”. You apparently specify the implementation (1.0 or 2.0) when add a source, destination, or port. The CoreMIDI package will translate when going between protocols. I’m currently on my phone and will add references when I get home.
The links below are to a GitHub project where I am trying to create sample MIDI programs. The first link contains a list of Apple CoreMIDI functions prior and after implementation of MIDI 2.0.
Michael B Kent
selected the reply #4875 as the answer for this post — 5 months ago
- Page :
- 1
There are no replies made for this post yet.
Be one of the first to reply to this post!
Be one of the first to reply to this post!