NRPN Messages

Many software and hardware use the following format when sending NRPN messages:

99 vv (parameter number MSB)
98 vv (parameter number LSB)
6 vv (parameter value MSB)
38 vv (parameter value LSB)
100 127 (parameter number 127 Null)
101 127 (parameter number 127 Null)

See link:

It seems that Shruthi don’t understand this syntax?
Is that true?

Thank you for your help.

The Shruthi understands 98, 98, 6, 38 ; not 100 / 101.

100 / 101 will just flow throw.

Do you think there would be a useful case for CC 100 / 101 ? From what I understood, the only thing it does is disable all the next CC 6 / 38 messages that are not preceded by a CC 99 / 98 message. The Philip rees page explains that it prevents a device from retaining “forever” the CC 99 / 98 parameter number. On the Shruthi this is reset when the device is powered off.


No, I do not think we should lose the memory for that.


I have another question:
What should it send to change a value between -63 and +63?

You need to use 2’s complement. For example, to set oscillator 1 pitch to -17:

99 00
98 02 (parameter 2)
6 1
38 111

Why? -17 in 2’s complement is 256-17 = 239 = 128 + 111 ; so the MSB is 128 / 128 = 1 and the LSB is 111

Yes, I understand, to code of -63 to + 63 requires that for negative numbers cc#6 = 1 and for positive numbers and cc# 6 = 0. We must therefore modify cc#6 and cc#38 at the same time.
This poses a problem because in many software for one potentiometer, one controller can be configured at once.

Any option you would suggest? Make all parameters start at 0 (so for example, for the modulation amount, 0 would set it to -63, 63 to 0, and 126 to 63)?

Yes, it’s a good solution to use standard programmer easier.
It remains to handle the positive value greater than 127 for the tempo. This will be adjusted slightly by accepting a loss of resolution in the adjustment by varying the value from 0 to 127 for 35 to 248.

I don’t like this scaling/loss of resolution approach. I’m OK to shift the negative parameters in a future version of the firmware, but using MSB/LSB to handle values above 127 is a normal way to do things and I don’t want to change anything for this point.

I quite agree with you on this point.
In addition, the use of DC # 96 (Inc) and CC # 97 (Dec) in version .92 firmware has another method of setting the tempo.
I’m eager to test the .92 version, when will. mid to download?