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 _______________________________________________ Linux-audio-user mailing list Linux-audio-user@email-addr-hidden http://lists.linuxaudio.org/listinfo/linux-audio-userReceived on Sun Jan 29 20:15:01 2017
This archive was generated by hypermail 2.1.8 : Sun Jan 29 2017 - 20:15:01 EET