Hi all,
I post here to submit some problem i think may occur with NRPNs.
I could have mailed directly to Murray but i think it will be better if all groups members are aware of this discussion. Because the issue could have consequences i'am not aware of and some of you experienced synth world explorers may know...
A little reminder on NRPN first:
--------------------------------
A NRPN message is a kind of "super" control change (CC for short) allowing to pass 14 bits parameters and data (value 0 to 16383) instead of the basic 7 bits of CC (value 0 to 127).
14 bits parameters are passed as two 7 bit values through CC $63 (99) and CC $62 (98) while 14 bits data are passed as two 7 bits values through CC $06 and CC $26 (38).
In theory a full NRPN message is in fact 4 CC as :
$Bx $63 <parameters' #, 7 most signifiant bits (msb)>
$Bx $62 <parameters' #, 7 least signifiant bits (lsb)>
$Bx $06 <data, 7 msb>
$Bx $26 <data, 7 lsb>
(note x stands for channel number $0 to $F)
It is allowed to omit some irrelevant message.
For instance, if parameter numbers don't go above 127, the message for the msb part can be omitted.
In the same manner, if the data doesn't go above 127, the message for the lsb (NOT the msb) can be omitted.
Note the difference here: the msb is sent as "coarse value". This allow emitting device to increase its data definition while staying compatible with receiving device with lower data resolution.
These rules (from the MIDI.ORG association) were neatly implemented in the Kiwi Upgrade: it uses only parameters number lsb and data value msb in two messages:
$Bx $62 <parameters' #>
$Bx $06 <data>
Note that in order to read correctly an incomming NRPN the receiver must wait to see if the data lsb arrives or not in a timely manner.
Also, if a new value is to be sent for the same parameter during the next seconds, the parameter number can be omited:
$Bx $06 <new data for same parameter>
Likewise, if a new value is to be sent for the same CC during the next seconds, the message header can be omitted !
<new data for same CC>
Real example, a series of message to change an NRPN driver parameter# $11 from value 0 to 5 could be sent as:
$B0 $62 $11
$B0 $06 0
1
2
3
4
5
All these variations allowed by the MIDI commitee can give some headhache to a programmer... I have been there ;)
But enough of theory, let's come to the problem i want to talk about.
The Issue:
----------
A device wanting to send an NRPN to the JX may well decide to send the full blown NRPN sequence (i.e. CCs $63, $62, $06, $26 )
If is fine for $63 because the JX ignores it.
But we have a problem with $26 because it is mapped to DCO 2 LFO Mod Amount in the current CC implementation...
So the big question is, should the parameter be mapped to some other free CC number 1 2 In this perspective, i propose... the next number wich isn't used yet : $27 (39).
Future compatibility planning:
------------------------------
In the same manner, CC# 0 and $20 (32) are reserved for bank change numbers. But the LFO2 Delay is actually mapped to CC# 32. Should it be changed too to allow for future enhancement and to be compatible with devices sending bank changes along program changes 1 2
The next free number would be $28 (40).
Thats all for now... hope i did not loose too many reader during my exposé ;)
Last thought, but it is worth an other discussion by itself: IMHO we should get rid of this NRPN non-sens and stick to plain CC. There are enough unused numbers in the list to map all JX parameters...
Bernard