# NRPN Messages

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

176
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)

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

Philippe.

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.

@Pichenettes

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

@Pichenettes

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:

176
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?