Quote:
Originally Posted by mschnell
Looks great !
Splitting up conrtol and feedback seems like a good idea.
I understand that "Fader14Bit" is the "special MCP Midi protocol" way of transferring 14 bit values (i.e. any Midi status can be use like 14 Bit pitchbend).
But there also is the standard 14 bit Midi protocol called "high resolution Midi CC". Here the high 7 bits are transferred as a normal CC and the low 7 bits are transferred as CC #+32. I don't know if there are any Control Surface devices that send or receive this mode, but if I would be to built one, I would implement it, as it is pure standard.  Maybe implementation in CSI could result in a "FaderLow7Bits" keyword to be used in combination with "Fader7Bit".
Code:
Fader7Bit e0 1f 7f e0 00 00
FaderLow7Bits e0 3f 7f e0 20 00
FB_Fader7Bit e0 1f 7f e0 00 00
FB_FaderLow7Bits e0 3f 7f e0 20 00
(If I correctly understand that with Fader7Bit the second and 5th hex code defines the range used with a Fader group. A goup of such faders could consist of only 32 faders instead of 128 in the normal 7 bit Fader7Bit variant.)
BTW.: What is the difference between "Fader7Bit" and "Encoder", If there is a difference, could a 14 bit encoder not be existing somewhere ?
-Michael |
Sure, you can pack/unpack the bits any way you like, we would just have to build supporting Widget components.
Fader14Bit -- 14 bit data, as you say, but limited to 16 Faders -- typically e0 - ef.
Fader7Bit (and switches) -- typically 90 xx 00-7f, where xx is control id.
Encoder -- typically b0 xx yy, where xx is control id and yy is just plus(+) and minus(-) increments -- sometimes only 2 values (e.g. 3f-41), but sometimes with acceleration, meaning more values.