In working further on my Ctrlr editor for the Shruthi, I can’t get the Ctrlr to respond to inbound NRPN messages from the Shruthi. I have the Shruthi’s MIDI mode set to “Ctlr”. Ctrlr thinks the inbound NRPN messages are “incomplete.” - See this thread: http://ctrlr.org/viewtopic.php?f=48&t=558 .
A “full” NRPN message is made of two bits:
From my experience with other synths, I have always been under the impression that once a parameter is selected, a stream of data entry or increment/decrement messages can be sent – ie, if you rotate the same pot, you don’t have to retransmit the parameter number part of the message at every value change. So the Shruthi tries to be parsimonious (and low-latency) in the MIDI data it sends, and only retransmits what has really changed.
My technical view on NRPNs - and the way it is implemented in my code - is that there are 4 registers per MIDI channel - parameter id MSB/LSB ; value MSB/LSB. Each incoming NRPN message writes the corresponding register. Furthermore, upon the reception of a data entry MSB/LSB message (depending on the data format used by the recipient), the parameter/value pair stored in the registers is committed to the patch memory of the synth. This view/implementation is consistent with retransmitting only the value when the same parameter is tweaked over and over again.
Now I would love to be pointed to any official document from the MIDI people explaining that those 4 messages should always be bundled together. This would simplify both the decoding side of thing, and the bit of code that removes the redundancy from the transmitted NRPN stream ; and I don’t want to miss an occasion to be lazy…
… at the risk of breaking compatibility with stuff sending NRPN in the parsimonious format…
Got it - as I speculated in the thread on ctrlr.org – it seems as though you’re basically sending a message in “running status” mode - just the data bit that’s changed, assuming the status bytes are not changing. I will post a message on the MIDI.org forum and see what they say.
FWIW, I found this in a Prophet 08 manual online (in the NRPN section):
“…The messages are handled in standard MIDI format using the NRPN CC commands in running status byte format…”
but then later:
“The parameter numbers and the parameter values are broken into two 7-bit bytes for MIDI transmission; the LSB has the seven least-significant bits, and the MSB has the seven mostsignificant bits, though in most cases the MSB will be zero or one, and never more than two. When receiving an NRPN, all messages do not necessarily need to be transmitted, since the synth will track the most recent NRPN number, though it is usually good practice to send the entire message above.”
While I investigate - do you (or others) have a list of synths that send NRPN the way the Shruthi does, so I can point atom to them?
The only synths I have left is a broken JX8-p (no MIDI), and a stack of half Shruthis - so no datapoint at hand. But one place to look at would be all the “parameter number + data slider” synths of the early 80s ; the UI of which (keypad to type a param number, data entry slider, inc/dec buttons) uncannily matches the spirit of the MIDI specs.
The first MIDI program I ever wrote was a generator of data entry messages because the data slider of my ESQ-1 was capricious. The only thing it did was to generated data entry CCs - I don’t remember inserting parameter number messages in the stream.
Another thought… If Dave Smith and the other people behind MIDI were crazy about the protocol being totally stateless, there wouldn’t be something like running status in the first place I think the motivation behind running status is 1/ to keep the latency down (some people say they can hear the 1ms it takes to send a full note on message) ; 2/ to try to make the most out of the limited bandwidth (with a few controllers and a sequence playing, simultaneous events could be played a few ms apart). It would be reasonable to assume that the same considerations would make unnecessary the rentransmission of the param number.
Great! A missed occasion to be lazy with MIDI parsing on my next project