On Sun, 29 Jan 2017 07:41:47 -0800 (PST) Len Ovens <len@xxxxxxxxxxxxx> wrote: > 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). Hmm, as a NRPN reciever, I've been doing a variation on that. I accept Nhigh and Nlow in either order, but only when both are valid respond to Dhigh and Dlow. These again I accept in either order and a message is delivered whenever both are valid (I set 128 as default). After that either can change independently. This avoids needing timeouts but does mean that sometimes two will be delivered in rapid sucession. That only happens if changing *both* data bytes without changing the NRPN. If either Nhigh or Nlow is changed both Dhigh and Dlow are set to default. I don't think it's right that changing an NRPN should resend (probably) stale and incorrect data. -- Will J Godfrey http://www.musically.me.uk Say you have a poem and I have a tune. Exchange them and we can both have a poem, a tune, and a song. _______________________________________________ Linux-audio-user mailing list Linux-audio-user@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/listinfo/linux-audio-user
