Firmware V1.28 Test Version

[XORadmin]

I did some research and I am not sure if the Arturia products send proper NPRN messages which use the 14 bit range for values at all. All I can see is that they send either coarse or fine and not both at the same time. (Like typically 3 packets instead of four which is theoretically OK following the Midi specs. But the specs are very inconsistent here and totally allow incompatibility between different gear) 
So you could send only one of these 2 parts per controller while you need both parts to create a 14 bit value. And each part is 7 bit = 128 divisions. What you end up with are a high amount of possible controllers bit each with only 128 steps. Using NRPN with these controllers would be a step back compared to just send CC.

I will email them up to find out if indeed those NRPNs are proper, as in, as per the midi.org information.

Talking about midi.org, I did find a table called something RPN https://midi.org/specifications-old/item...ta-bytes-2 and found some values that were similar to the ones I had played with last time, but the result was similar, as in still in the 128 div range, but here again, I aint an expert with that, so I may post my question to Modwiggler and see if I can gather anything of interest.

I mean, I can start with creating my live system with only midi cc values but I'm so close to get a definite response to see if its possible or not that it would be foolish for me to let go of my diggings. Even though, I may find a work arounds, who knows.

This midi 2.0 makes a lot of sense to me, and yes I remember that the last upgrade didn't take off, but this time it seems like they are onto something definately of interst, at least for those like myself who wants to record modulations and be able to recall knob positions out of a midi click.

Well they follow the specification. But the specification allows to just use 128 steps with just not sending another additional packet.
They are enough discussions out there, also about Arturias implementations.

...recall knob positions out of a midi click.

That is called program change :-)

From the RPN sheet of Midi.org you linked to (Where RPN is similar to NRPN with it's packet arrangement)
"2. To set the selected Registered Parameter to a specific value, send a Control Change messages to the Data Entry MSB controller (Control Number 6). If the selected Registered Parameter requires the LSB to be set, send another Control Change message to the Data Entry LSB controller (Control Number 38)."

This shows it nicely:
The LSB is optional which makes it a really weird thing as the receiving side can't really wait until that last packet for the LSB comes or doesn't come. So if the sender allows only 128 steps anyways, then they most probably skip that last byte, but then it doesn't make sense at all to use NRPN for it (except if you have more than 128 parameter types on the receiver side). Then it is 2 or 3 bytes vs. 9 or 6 bytes for the same thing. Also if it uses 14 bits, then it is even 12/8 bytes and that would mean that higher resolution comes at a cost of midi data traffic AND a significant delay until the complete package is sent out (people even say that this is audible).
Just to be sure, this is not a NerdSEQ issue! I will allow it to receive 14 bit NRPN messages. But the 7 bit ones don't make sense here and will not be supported.