You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
The text was updated successfully, but these errors were encountered: