From the MIDI-CI p29 spec it looks like the test message in the new negotiated protocol is still a MIDI 1.0 F0-F7 formatted Sysex message ?
Should it not be in UMP when MIDI 2.0 UMP is selected ? Assume "p23 0x02 MIDI 2.0 Protocol" mean UMP ?
The MIDI 1.0 Protocol bracketing method with 0xF0 Start and 0xF7 End Status bytes is not used in the UMP Format.
MIDI 2.0 Protocol: Version 2.0 of the MIDI Protocol, as defined in this specification. The native format for MIDI 2.0 messages is UMP
Should it not be in UMP when MIDI 2.0 UMP is selected ? Assume "p23 0x02 MIDI 2.0 Protocol" mean UMP ?
The MIDI 1.0 Protocol bracketing method with 0xF0 Start and 0xF7 End Status bytes is not used in the UMP Format.
MIDI 2.0 Protocol: Version 2.0 of the MIDI Protocol, as defined in this specification. The native format for MIDI 2.0 messages is UMP
>all Protocol Negotiation messages will probably be used in the UMP forma
>
>Though the spec on p.3 states:
>Devices default to using MIDI 1.0 and only use extended MIDI features after two Devices have agreed via MIDI-CI to use those extended features.
MIDI 1.0 can run on the Universal MIDI Packet. It's a bit confusing, but this is all designed to be transport agnostic. So a MIDI 1.0 device running on a transport that is using the Universal MIDI Packet is still a MIDI 1.0 device.
>Q1: This MIDI 1.0 default is in the current, MIDI 1.0, Sysex F0.. f7 format, thus not UMP ?
>Q2: Thus even the test messages on p.29 states
>The Initiator sends this confirmation test message in the new Protocol.
>and shows a MIDI 1.0 Sysex F0/F7 message this actually should be UMP Sysex8 UMP without the F0/F7.
>Q3: If I understand this correctly, both the initiator and responder starts in MIDI 1.0 (using for example
>current (USB) MIDI 1.0 device descriptors) and sends >a MIDI 1.0 BYTE formatted Universal F0..F7
>Sysex MIDI. Once the responder has accepted the new protocol the initiator sends a test message in UMP.
>Correct ?
No. The MIDI-CI specification states that Protocol Negotiation basically requires the UMP to be in place first.
>Q4: Does this mean that Profile and property exchange must be in UMP Sysex ? So far assumed that Property
> and Profile exchange could still be done using the MIDI 1.0 Sysex format. Perhaps that is not the case?
Profile Configuration and Property Exchange do no require the UMP.
> Q5: The UMP spec states that protocol negotiation is on a per group bases, The Protocol negotation
> message (F0...F7 example) seems not have such "Group" field, how would the switch work per group
> for devices both supporting only MIDI 1.0 and 2.0 for different groups ? Would the devices first switch
> "globally" (MIDI 1.0 F0..F7) to UMP and then negotiate the protocol on a per group bases using the
>UMP group field ?
The MIDI-CI specification states that Protocol Negotiation basically requires the UMP to be in place first. So the messages will have a Group field. We may define how to use UMP on 5 pin DIN in the future, which would require a switch of data format as well. IMO, if we do so, we should define that only one Group is supported on 5 pin DIN.
>Q6:
>Those transports are expected to have the UMP as the native format for both MIDI 1.0 and MIDI 2.0.
>Does that mean there will be USB devices that only recognize UMP messages and
>won't recognize MIDI 1.0 BYTE formatted messages at startup and MIDI-CI protocol negotiation
>in UMP won't be not required (but optional on a per group bases if the sender wishes to do so)
There is a new USB MIDI specification in progress. Those questions are answered in that specification. But the specification is not public yet.
>Perhaps there could be a wok in progress document "clarifications to the MIDI 2.0 specification"
Yes. MMA members can contribute to that document under the IP agreement of the MMA.
Mike.
>
>Though the spec on p.3 states:
>Devices default to using MIDI 1.0 and only use extended MIDI features after two Devices have agreed via MIDI-CI to use those extended features.
MIDI 1.0 can run on the Universal MIDI Packet. It's a bit confusing, but this is all designed to be transport agnostic. So a MIDI 1.0 device running on a transport that is using the Universal MIDI Packet is still a MIDI 1.0 device.
>Q1: This MIDI 1.0 default is in the current, MIDI 1.0, Sysex F0.. f7 format, thus not UMP ?
>Q2: Thus even the test messages on p.29 states
>The Initiator sends this confirmation test message in the new Protocol.
>and shows a MIDI 1.0 Sysex F0/F7 message this actually should be UMP Sysex8 UMP without the F0/F7.
>Q3: If I understand this correctly, both the initiator and responder starts in MIDI 1.0 (using for example
>current (USB) MIDI 1.0 device descriptors) and sends >a MIDI 1.0 BYTE formatted Universal F0..F7
>Sysex MIDI. Once the responder has accepted the new protocol the initiator sends a test message in UMP.
>Correct ?
No. The MIDI-CI specification states that Protocol Negotiation basically requires the UMP to be in place first.
>Q4: Does this mean that Profile and property exchange must be in UMP Sysex ? So far assumed that Property
> and Profile exchange could still be done using the MIDI 1.0 Sysex format. Perhaps that is not the case?
Profile Configuration and Property Exchange do no require the UMP.
> Q5: The UMP spec states that protocol negotiation is on a per group bases, The Protocol negotation
> message (F0...F7 example) seems not have such "Group" field, how would the switch work per group
> for devices both supporting only MIDI 1.0 and 2.0 for different groups ? Would the devices first switch
> "globally" (MIDI 1.0 F0..F7) to UMP and then negotiate the protocol on a per group bases using the
>UMP group field ?
The MIDI-CI specification states that Protocol Negotiation basically requires the UMP to be in place first. So the messages will have a Group field. We may define how to use UMP on 5 pin DIN in the future, which would require a switch of data format as well. IMO, if we do so, we should define that only one Group is supported on 5 pin DIN.
>Q6:
>Those transports are expected to have the UMP as the native format for both MIDI 1.0 and MIDI 2.0.
>Does that mean there will be USB devices that only recognize UMP messages and
>won't recognize MIDI 1.0 BYTE formatted messages at startup and MIDI-CI protocol negotiation
>in UMP won't be not required (but optional on a per group bases if the sender wishes to do so)
There is a new USB MIDI specification in progress. Those questions are answered in that specification. But the specification is not public yet.
>Perhaps there could be a wok in progress document "clarifications to the MIDI 2.0 specification"
Yes. MMA members can contribute to that document under the IP agreement of the MMA.
Mike.
0
Undo
Votes
There are many specifications that show SysEx messages in F0…F7 form. All of them must be encoded differently when UMP is used.
MIDI 1.0 is the lowest common denominator for all devices (MIDI-CI does not imply UMP), so it makes sense to show SysEx messages in this form.
MIDI 1.0 is the lowest common denominator for all devices (MIDI-CI does not imply UMP), so it makes sense to show SysEx messages in this form.
We chose to document all System Exclusive messages in their MIDI 1.0 format just to be consistent. The format in the Universal MIDI Packet removes the need for the F0 and F7 for all messages. In fact, all Protocol Negotiation messages will probably be used in the UMP format. At this time there is no specification to support UMP on 5 pin DIN. At least at this time, Protocol Negotiation will only work on new transports that support the UMP format. Those transports are expected to have the UMP as the native format for both MIDI 1.0 and MIDI 2.0.
all Protocol Negotiation messages will probably be used in the UMP forma
Though the spec on p.3 states:
Devices default to using MIDI 1.0 and only use extended MIDI features after two Devices have agreed via MIDI-CI to use those extended features.
Q1: This MIDI 1.0 default is in the current, MIDI 1.0, Sysex F0.. f7 format, thus not UMP ?
Q2: Thus even the test messages on p.29 states
The Initiator sends this confirmation test message in the new Protocol.and shows a MIDI 1.0 Sysex F0/F7 message in practice this is a UMP Sysex7 UMP without the F0/F7.
Q3: If I understand this correctly, both the initiator and responder starts in MIDI 1.0 (using for example current (USB) MIDI 1.0 device descriptors) and sends a MIDI 1.0 BYTE formatted Universal F0..F7 Sysex MIDI. Once the responder has accepted the new protocol the initiator sends a test message in UMP. Correct ?
Q4: Does this mean that Discovery, Disovery Reply, Test and further on the Profile and property exchange must be in UMP Sysex ? So far assumed that Discovery, Discovery reply/ACK, Test, Property and Profile exchange could still be done using the MIDI 1.0 Sysex format. Perhaps that is not the case?
Q5: The UMP spec states that protocol negotiation is on a per group bases, The Protocol negotation message (F0...F7 example) seems not have such "Group" field, how would the switch to MIDI 2.0 protocol work per group for devices both supporting only MIDI 1.0 and 2.0 for different groups ? Would the devices first switch "globally" (MIDI 1.0 F0..F7) to UMP and then negotiate the protocol on a per group bases using the UMP group field as p.16 of the UMP spec states
On a per-Group basis, the Sender and Receiver shall cooperatively select exactly one MIDI Protocol at at time using either the MIDI-CI mechanism
MIDI-CI protocol spec states the default to the MIDI 1.0 (F0.F7) BYTE format p.29, this is very confusing.
Q6:
Those transports are expected to have the UMP as the native format for both MIDI 1.0 and MIDI 2.0.Does that mean there will be USB devices that only recognize UMP messages and won't recognize MIDI 1.0 BYTE formatted messages at startup and MIDI-CI protocol negotiation in UMP won't be not required (but optional on a per group bases if the sender wishes to do so)
Perhaps there could be a wok in progress document "clarifications to the MIDI 2.0 specification"
>all Protocol Negotiation messages will probably be used in the UMP forma
>
>Though the spec on p.3 states:
>Devices default to using MIDI 1.0 and only use extended MIDI features after two Devices have agreed via MIDI-CI to use those extended features.
MIDI 1.0 can run on the Universal MIDI Packet. It's a bit confusing, but this is all designed to be transport agnostic. So a MIDI 1.0 device running on a transport that is using the Universal MIDI Packet is still a MIDI 1.0 device.
>Q1: This MIDI 1.0 default is in the current, MIDI 1.0, Sysex F0.. f7 format, thus not UMP ?
>Q2: Thus even the test messages on p.29 states
>The Initiator sends this confirmation test message in the new Protocol.
>and shows a MIDI 1.0 Sysex F0/F7 message this actually should be UMP Sysex8 UMP without the F0/F7.
>Q3: If I understand this correctly, both the initiator and responder starts in MIDI 1.0 (using for example
>current (USB) MIDI 1.0 device descriptors) and sends >a MIDI 1.0 BYTE formatted Universal F0..F7
>Sysex MIDI. Once the responder has accepted the new protocol the initiator sends a test message in UMP.
>Correct ?
No. The MIDI-CI specification states that Protocol Negotiation basically requires the UMP to be in place first.
>Q4: Does this mean that Profile and property exchange must be in UMP Sysex ? So far assumed that Property
> and Profile exchange could still be done using the MIDI 1.0 Sysex format. Perhaps that is not the case?
Profile Configuration and Property Exchange do no require the UMP.
> Q5: The UMP spec states that protocol negotiation is on a per group bases, The Protocol negotation
> message (F0...F7 example) seems not have such "Group" field, how would the switch work per group
> for devices both supporting only MIDI 1.0 and 2.0 for different groups ? Would the devices first switch
> "globally" (MIDI 1.0 F0..F7) to UMP and then negotiate the protocol on a per group bases using the
>UMP group field ?
The MIDI-CI specification states that Protocol Negotiation basically requires the UMP to be in place first. So the messages will have a Group field. We may define how to use UMP on 5 pin DIN in the future, which would require a switch of data format as well. IMO, if we do so, we should define that only one Group is supported on 5 pin DIN.
>Q6:
>Those transports are expected to have the UMP as the native format for both MIDI 1.0 and MIDI 2.0.
>Does that mean there will be USB devices that only recognize UMP messages and
>won't recognize MIDI 1.0 BYTE formatted messages at startup and MIDI-CI protocol negotiation
>in UMP won't be not required (but optional on a per group bases if the sender wishes to do so)
There is a new USB MIDI specification in progress. Those questions are answered in that specification. But the specification is not public yet.
>Perhaps there could be a wok in progress document "clarifications to the MIDI 2.0 specification"
Yes. MMA members can contribute to that document under the IP agreement of the MMA.
Mike.
>
>Though the spec on p.3 states:
>Devices default to using MIDI 1.0 and only use extended MIDI features after two Devices have agreed via MIDI-CI to use those extended features.
MIDI 1.0 can run on the Universal MIDI Packet. It's a bit confusing, but this is all designed to be transport agnostic. So a MIDI 1.0 device running on a transport that is using the Universal MIDI Packet is still a MIDI 1.0 device.
>Q1: This MIDI 1.0 default is in the current, MIDI 1.0, Sysex F0.. f7 format, thus not UMP ?
>Q2: Thus even the test messages on p.29 states
>The Initiator sends this confirmation test message in the new Protocol.
>and shows a MIDI 1.0 Sysex F0/F7 message this actually should be UMP Sysex8 UMP without the F0/F7.
>Q3: If I understand this correctly, both the initiator and responder starts in MIDI 1.0 (using for example
>current (USB) MIDI 1.0 device descriptors) and sends >a MIDI 1.0 BYTE formatted Universal F0..F7
>Sysex MIDI. Once the responder has accepted the new protocol the initiator sends a test message in UMP.
>Correct ?
No. The MIDI-CI specification states that Protocol Negotiation basically requires the UMP to be in place first.
>Q4: Does this mean that Profile and property exchange must be in UMP Sysex ? So far assumed that Property
> and Profile exchange could still be done using the MIDI 1.0 Sysex format. Perhaps that is not the case?
Profile Configuration and Property Exchange do no require the UMP.
> Q5: The UMP spec states that protocol negotiation is on a per group bases, The Protocol negotation
> message (F0...F7 example) seems not have such "Group" field, how would the switch work per group
> for devices both supporting only MIDI 1.0 and 2.0 for different groups ? Would the devices first switch
> "globally" (MIDI 1.0 F0..F7) to UMP and then negotiate the protocol on a per group bases using the
>UMP group field ?
The MIDI-CI specification states that Protocol Negotiation basically requires the UMP to be in place first. So the messages will have a Group field. We may define how to use UMP on 5 pin DIN in the future, which would require a switch of data format as well. IMO, if we do so, we should define that only one Group is supported on 5 pin DIN.
>Q6:
>Those transports are expected to have the UMP as the native format for both MIDI 1.0 and MIDI 2.0.
>Does that mean there will be USB devices that only recognize UMP messages and
>won't recognize MIDI 1.0 BYTE formatted messages at startup and MIDI-CI protocol negotiation
>in UMP won't be not required (but optional on a per group bases if the sender wishes to do so)
There is a new USB MIDI specification in progress. Those questions are answered in that specification. But the specification is not public yet.
>Perhaps there could be a wok in progress document "clarifications to the MIDI 2.0 specification"
Yes. MMA members can contribute to that document under the IP agreement of the MMA.
Mike.
Dear Kent, Thank you for taking the time for this excellent clarification that we need to boot /power on MIDI 2.0 devices in UMP (without the F0/F7) as default. My misunderstanding was that protocol switching related to switching from MIDI 1.0 (F0/F7) byte stream to UMP but it's more a kind of feature set switch under UMP. Understand that to encapsulate UMP into a new MIDI 1.0 universal SYSEX message (a MIDI 1.0 SYSEX UMP MIDI 1.0 or 2.0 message) would take some effort, but may really be a very nice thing to have to support older hardware with a firmware update without needing new USB descriptors and operating system/drivers etc..
- Page :
- 1
There are no replies made for this post yet.
