[LAU] USB MIDI controller - update

[Len Ovens]

On Sun, 29 Jan 2017, termtech wrote:

> On Saturday, January 28, 2017 2:37:40 PM EST Len Ovens wrote:
>> That could very well be why Mackie limited their faders to 10 bits (last 4
>> bits zeroed).
>
> I am interested to know /how/ it sends out the 14 bits.
> Hi byte first? Or low byte? Or selectable?
> And can it optimize by not sending redundant hi or low bytes,
> or redundant NRPN numbers?

In the mackie case and bcf2k in mackie/LC mode, faders are sent as pitch. 
So the MSB and LSB are included in one event and both are sent every time.

In NRPN case... things are different. The receiver should respond to any 
one of the four events based on the last received values for the the other 
three. It is quite common though in the case of receiving the MSB to check 
the following event to see if LSB has changed as well. The four events
should always be sent in order. Events can be left off starting at the 
first event, but once one of the events is sent, all following events are 
sent.... sort of. The last event is optional (at least some manufactures 
treat it so - like Allen & Heath) so a receiver has to check if the last 
event is there or not using a short timeout (time to transmit one byte or 
event depending on the parser).

Best practice for transmitting is considered to be sending all four events 
every time. This accounts (mostly) for such things as merged MIDI signals. 
In theory, a MIDI merger should consider the four nrpn events as one event 
and should create a new four part event even if only one is received and 
then send the whole event without interleaving. However, I suspect most 
just interleave by the standard midi event (1, 2 or 3 bytes).

--
Len Ovens
www.ovenwerks.net