NRPN issues - can't go past NRPN #256

MIDIbox NG
1

hello friends,

i have a problem with my rotary encoders sending several banks of midi NRPN data - i can’t go past NRPN number 256! the second byte of the midi nrpn number message (ie. midi CC 99) midibox sends only goes from 0 to 1, as shown on the mios studio output monitor.

it says in the manual that the nrpn number is also 14bit range as per the midi standard

nrpn=\<0..16383\> Specifies the NRPN number (0..16383) for type=NRPN events

is this a known issue? am i doing something wrong (presumably…)

this is an EVENT ENC definition that shows:

EVENT\_ENC id= 55 hw\_id=7 bank=3 type=nrpn nrpn=261 chn= 1 range= 4095:0 enc\_speed\_mode=fast:6 offset= 0 ports=10001000000010000000 lcd\_pos=1:1:1 label="^std\_enc" value= 0

Quote

 

so, this give me CC99 = 1 CC98 = 5, NRPN = 133

instead of CC99 = 2 cc98 = 5, NRPN = 261

that i wanted. only the first bit of CC99 seems to be changed, effectively giving me 8bit range.

 

2

I think I ran into this problem also a while ago. Unfortunately I don’t have a fix for that issue. 

3

i gguess worst case i can work around by sendin gthe first 256 on channel 1 and then a second set of 256 NRPNs on channel 2 would be enough for me. just have to decode back to the original numbering on the receiver side.

4

Did you check with an other midi monitor, like midi-ox(PC) or snoize(MAC)

Just to be sure it’s not a mios studio issue.

5

on the receiver side i am monitoring the midi incoming from the midibox with the axoxloti serial monitor, which shows the same value that mios studio shows sending.

so, mios studio seems to display the “correct” values that are actually being sent. just CC99 only ranges from 0-1 instead 0-127.

6

did you try the value in hexadecimal instead of decimal just to see?

nrpn=261 is nrpn=0x105

7

oh you mean in the NGC config? i will try that as soon as i am with the hardware again, thanks.

8

Anyway we will do a small debug test…
For that you will need to recompile the MBNG app after modification…

in mbng_file_c.c at line 812

replace this:

//////////////////////////////////////////////////////////////////////////////////////////////// } else if( strcasecmp(parameter, "nrpn") == 0 ) { int value; if( (value=get\_dec(value\_str)) \< 0 || value \>= 16384 ) { #if DEBUG\_VERBOSE\_LEVEL \>= 1 DEBUG\_MSG("[MBNG\_FILE\_C:%d] ERROR: invalid NRPN number in EVENT\_%s ... %s=%s\n", line, event, parameter, value\_str); #endif return -1; } else { if( item.flags.type != MBNG\_EVENT\_TYPE\_NRPN ) { #if DEBUG\_VERBOSE\_LEVEL \>= 1 DEBUG\_MSG("[MBNG\_FILE\_C:%d] WARNING: no NRPN number expected for EVENT\_%s due to type: %s\n", line, event, MBNG\_EVENT\_ItemTypeStrGet(&item)); #endif } else { // no extra check if event\_type already defined... stream[1] = value & 0xff; stream[2] = value \>\> 8; item.secondary\_value = stream[1]; } } ////////////////////////////////////////////////////////////////////////////////////////////////

by

//////////////////////////////////////////////////////////////////////////////////////////////// } else if( strcasecmp(parameter, "nrpn") == 0 ) { int value; if( (value=get\_dec(value\_str)) \< 0 || value \>= 16384 ) { #if DEBUG\_VERBOSE\_LEVEL \>= 1 DEBUG\_MSG("[MBNG\_FILE\_C:%d] ERROR: invalid NRPN number in EVENT\_%s ... %s=%s\n", line, event, parameter, value\_str); #endif return -1; } else { if( item.flags.type != MBNG\_EVENT\_TYPE\_NRPN ) { #if DEBUG\_VERBOSE\_LEVEL \>= 1 DEBUG\_MSG("[MBNG\_FILE\_C:%d] WARNING: no NRPN number expected for EVENT\_%s due to type: %s\n", line, event, MBNG\_EVENT\_ItemTypeStrGet(&item)); #endif } else { // no extra check if event\_type already defined... stream[1] = value & 0x7f; stream[2] = value \>\> 7; item.secondary\_value = stream[1]; } } ////////////////////////////////////////////////////////////////////////////////////////////////

Cause !
In this part of the parser there’s something strange which is disturbing me at the end when the address is store in the item->stream we’ve got:

 // no extra check if event\_type already defined... stream[1] = value & 0xff; stream[2] = value \>\> 8; item.secondary\_value = stream[1];

but in the MBNG_EVENT_TYPE_NRPN part of the MBNG_EVENT_ItemSend function we’ve got:

 u16 nrpn\_address = item-\>stream[1] | ((u16)item-\>stream[2] \<\< 7);

if I make the calculation like it is I find exactly your problem:

In parser
stream[1] = 261 & 0xff = 5
stream[2] = 261 >> 8 = 1

then in MBNG_EVENT_ItemSend
u16 nrpn_address = item->stream[1] | ((u16)item->stream[2] << 7) = 5 | (1<<7) = 133

Address msb is not limited to 0 or 1, I think it’s a masking and shifting error and bit 7 is lost, so make the test with

// no extra check if event\_type already defined... stream[1] = value & 0x7f; stream[2] = value \>\> 7; item.secondary\_value = stream[1];

Please

 

9

I also remember a problem like this. But somehow I was able to get around it as I even made a video where I could vary the NRPN to access all 360 hues of a WS2812. I had a look at my NGC and could see nothing special configured.

So please follow Bruno’s advice, maybe he has found the problem.

10

yeah thanks this seems to make a lot of sense, will try first thing tomorrow. i also should have tried to go to nrpn values that would have used the next bit.

11

I can confirm Brunos changes work well! :slight_smile:

1 Like
12

2 hours ago, FantomXR said:

I can confirm Brunos changes work well! :slight_smile:

Thanks man for having checking it.
We can now put TK in the loop…
:wink: if you confirm it too, it can be modified in the repo.

Best regards
Bruno