a regular NRPN editor will *appear* to work, but in fact is always at least one data update behind, as the VS is waiting for the MSB packet to commit the change. this packet arrives as part of the *next* parameter change packet sequence. and technically, the MSB only needs to be sent if the MSB of the value changes, so if the controller implements that, it could be a while...
i think this is why the official NRPN spec is big endian, as lots of MSB packets can be saved if only the LSB changes, which is most of the time. the VS version is more wasteful on the wire.
i found all this out the hard way, before i knew anything about the VS implementation, using an Encore Electronics Knobby to control my VS. i talked to Tony K (now chief hardware guy at DSI) about it and they actually did implement a little-endian mode in the Knobby for the VS as a result (thanks guys).
so for accurate parameter changes from NRPN controllers, the input code needs to be swapped too.
thanks for tunnelling through the code and sorting this out!
On Sun, Aug 5, 2018 at 8:16 PM, shalebridge@... [prophet_vs] <prophet_vs@yahoogroups.com> wrote:
So, I got the NRPN out messages to be correct by rearranging the code (see image). It looks like it was only the output messages that were flipped though.Flipping the input bytes breaks the incoming message and no NRPN codes work. In fact using original 1.0 & 1.2 eproms it looks like the VS already read the input NRPN correctly, based on watching the messages in MIDI-OX. I send it this message in this order from an Arturia BeatStep Pro in NRPN mode:99 0 NRPN MSB98 12 NRPN LSB6 (*) DATA MSBAnd it controls the Cutoff Freq just fine.