weasel Posted October 4, 2019 Report Share Posted October 4, 2019 (edited) 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. Edited October 5, 2019 by weasel Quote Link to comment Share on other sites More sharing options...
FantomXR Posted October 6, 2019 Report Share Posted October 6, 2019 I think I ran into this problem also a while ago. Unfortunately I don't have a fix for that issue. Quote Link to comment Share on other sites More sharing options...
weasel Posted October 6, 2019 Author Report Share Posted October 6, 2019 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. Quote Link to comment Share on other sites More sharing options...
Antichambre Posted October 6, 2019 Report Share Posted October 6, 2019 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. Quote Link to comment Share on other sites More sharing options...
weasel Posted October 6, 2019 Author Report Share Posted October 6, 2019 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. Quote Link to comment Share on other sites More sharing options...
Antichambre Posted October 6, 2019 Report Share Posted October 6, 2019 did you try the value in hexadecimal instead of decimal just to see? nrpn=261 is nrpn=0x105 Quote Link to comment Share on other sites More sharing options...
weasel Posted October 6, 2019 Author Report Share Posted October 6, 2019 oh you mean in the NGC config? i will try that as soon as i am with the hardware again, thanks. Quote Link to comment Share on other sites More sharing options...
Antichambre Posted October 6, 2019 Report Share Posted October 6, 2019 (edited) 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 Edited October 6, 2019 by Antichambre Quote Link to comment Share on other sites More sharing options...
latigid on Posted October 6, 2019 Report Share Posted October 6, 2019 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. Quote Link to comment Share on other sites More sharing options...
weasel Posted October 6, 2019 Author Report Share Posted October 6, 2019 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. Quote Link to comment Share on other sites More sharing options...
FantomXR Posted October 9, 2019 Report Share Posted October 9, 2019 I can confirm Brunos changes work well! :-) 1 Quote Link to comment Share on other sites More sharing options...
Antichambre Posted October 9, 2019 Report Share Posted October 9, 2019 2 hours ago, FantomXR said: I can confirm Brunos changes work well! :-) Thanks man for having checking it. We can now put TK in the loop...@TK. ;) if you confirm it too, it can be modified in the repo. Best regards Bruno Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.