Seems like this could be prototyped using existing CC handlers in oopsy, and a bit of math for the MSB/LSB handling, and some logic for the possibly sequential nature.
If it seems solid and workable, it should be feasible to create e.g. param midi_nrpn_XYZ and history midi_nrpn_XYZ_out etc., where XYZ refers to the NRPN type.
I note that I've seen some quite inconsistent and strange uses of NRPN by different hardware, so I'm a bit hesitant to push for something that might be an endless series of cases that don't work... but I admit I've never really dealt with them so maybe there is a generalized and flexible pattern that can be used.
Per thread here: https://forum.electro-smith.com/t/is-there-an-nprn-encode-decode-supported-by-default/1669
Some notes from the thread:
Seems like this could be prototyped using existing CC handlers in oopsy, and a bit of math for the MSB/LSB handling, and some logic for the possibly sequential nature.
If it seems solid and workable, it should be feasible to create e.g. param midi_nrpn_XYZ and history midi_nrpn_XYZ_out etc., where XYZ refers to the NRPN type.
I note that I've seen some quite inconsistent and strange uses of NRPN by different hardware, so I'm a bit hesitant to push for something that might be an endless series of cases that don't work... but I admit I've never really dealt with them so maybe there is a generalized and flexible pattern that can be used.