Notifications
Clear all
Topic starter
[1] Page 104 states
• a CC 38 is received
• a subsequent CC 6 is received
• a CC 98, 99, 100, and 101 is received, indicating the last RPN/NRPN message has ended and a new one
has started
I guess this not the correct and proper sequence to send a MIDI 2.0 assignable or registered parameter value should be
(N)RPN number LSB (optional, some devices and software don't send it), default to zero
(N)RPN number MSB
value LSB (38) - (optional, some devices and software don't send it), default to zero
value MSB (06) - mandatory
Send message
[2] The MIDI 2.0 spec omits what to do with CC 96 & 97. in my opinion.
if CC96 = 00, increment with 1 because some devices don't use the value. if > 0 increment with the value , with maximum of 0x7F
if CC97 = 00, then decrement with 1, because some devices dont use the value if > 0 decrement with the value with a minimum of 0x00
[3] The spec states there are 16384 controllers, this should be not correct, 0x7F MSB/LSB are not translated so there are 0x7E * 0x7E controllers.
Posted : 30/07/2024 1:27 am
Topic starter
[4] The spec puts the LSB and MSB values in bits 31-24. This is not wrong but a bit weird, It result in bits 31 and 24 always 0.
Should the correct upscaling from 14 to 32 bits not be (MSB << 7 | LSB ) << 18; ?
This post was modified 4 months ago by Muzak
Posted : 30/07/2024 1:37 am
Topic starter
[4] The spec puts the LSB and MSB values in bits 31-24. This is not wrong but a bit weird, It result in bits 31 and 24 always 0.
Should the correct upscaling from 14 to 32 bits not be (MSB << 7 | LSB ) << 18; ?
Would this also mean when downscaling a 32 bit value from a host to legacy 14 bits to mask bits 31 and 24 and then move bits 25-31 into the MSB and bits 23-17 into LSB ? The UMP spec defines how to translate from 7 bits to 32 bits but not the other way around.
Posted : 30/07/2024 2:27 am
Topic starter
[5] for Special RPN's 3,4, and 6, in case the source is a legacy device, the values are taken from CC 06 or CC38 ? Assume it's is CC 06 MSB as 38 is often not used. and for RPN 0, cents is the LSB and semitones the MSB ?
Posted : 30/07/2024 2:35 am
Topic starter
Please ignore question [4]. (Wrongly read the spec)
Posted : 30/07/2024 8:14 am
Regarding [2], the UMP specification says (at P.104):
> MIDI 1.0 Protocol Increment (CC 96) and Decrement (CC 97) messages are translated to Control Change messages in the MIDI 2.0 Protocol. They have no RPN/NRPN related function in the MIDI 2.0 Protocol. They should not be translated to MIDI 2.0 Relative Registered Controller and Relative Assignable Controller Messages.
(To my understanding, they are not translated to messages with the new status code because of the value range difference.)
I kind of agree to the idea that requiring CC38 as mandatory is a bit too extreme, but since Appending D.3 is only about the "Default" translation we could always relax the limitation in our implementations (I'm also curious to know if we should not do so for some reason).
Posted : 09/08/2024 2:29 am
Topic starter
Thanks the question was if zero 0 from legacy MIDI messages should be interpreted as an increase/decrease or not for the value in the UMP message.
For the other, no answers from MIDI.ORG ...
Posted : 14/08/2024 11:35 pm
Topic starter
[5] for single value special RPN the UMP messages should use from legacy data entry 06 (LSB), for 14 bits is 06 LSB and 238 MSB
For [2] still not sure what to do when receiving a legacy dec/inc with 0, Should increase/Decrease the UMP RPN value or not ? (and the other way around)
Posted : 19/08/2024 5:51 pm
