NRPN woes

Discontinued DIY products Shruthi
#1

Hey, so I’m trying to program my BCR 2000 to send proper NRPN messages and I can’t seem to get it right… Hoping someone can shed some light on how this is supposed to work.

So for each knob I can assign MIDI channel (currently 1, which is 0 in shrutiland). Then there’s the parameter #, (NRPN #) which varies from 0 to 16,383. Presumably since I don’t need MSB i’m just concerned with values from 0 to 94. In my experiments I’ve been trying to change 2 & 3, which correspond to OSC 1 & 2 parameter values. I figured it would be easy to hear, and seemed like the most straightforward (no negative values or anything like that). So I’d set the BCR knob’s NRPN # to 2. Then there are min and max settings for the knob. These are 0-127 or 0-16,383 depending on which NRPN mode I’m in, which comes to the crux of my question:

These are the formats the BCR supports. From the manual:

“CONTINUOUS-type element controls are divided into “Absolute”, “Absolute (14 bit),” “Relative 1” (2nd complement), “Relative 2” (binary offset), “Relative 3” (MSB, most significant bit), “Relative 1 (14 bit),” “Relative 2 (14 bit)”, “Relative 3 (14 bit)” and “Increment/Decrement.” Absolute means absolute data values although jumps may occur when changing values. With Relative, the current parameter value is continued independently from the position of the control. Absolute (14-Bit) or one of the Relative (14-Bit_ modes are standard modes for value changes at NRPNs with high resolution. This is necessary with some software mixers if more than 128 steps are needed. Increment/Decrement serves as a step-by-step increase or decrease of values by using the Data Increment/Decrement commands.”

This is all of the info I can discover on it. pretty cryptic to me. And from what I’ve gathered on the internet, it supposedly doesn’t support negative values, which sucks if true.

Anyway, this difficulty of figuring this all out is compounded by the fact that the display doesn’t follow incoming control data. (or does it?) I do get changes to happen, often what happens is I change the value, change the page a couple of times to see if the value has changed in the Shruti, and it’s stuck at 255 or 0.

Any ideas? I may have to bust out MIDI-OX soon.

#2
  1. One first thing regarding the channel: 0 means “all channels”, while 1 means “channel 1”.
  2. NRPN changes do not show up on the display.

Do you have a MIDI monitoring app ? or a plain sequencer, to record what happens when you tweak ?

#3

TIMESTAMP IN PORT STATUS DATA1 DATA2 CHAN NOTE EVENT
173115 16 – 176 99 0 1 — CC: NRPN MSB
173116 16 – 176 98 3 1 — CC: NRPN LSB
173117 16 – 176 6 0 1 — CC: Data Entry MSB
173119 16 – 176 38 0 1 — CC: Data Entry LSB
177872 16 – 176 99 0 1 — CC: NRPN MSB
177873 16 – 176 98 3 1 — CC: NRPN LSB
177874 16 – 176 6 0 1 — CC: Data Entry MSB
177875 16 – 176 38 1 1 — CC: Data Entry LSB
178262 16 – 176 99 0 1 — CC: NRPN MSB
178263 16 – 176 98 3 1 — CC: NRPN LSB
178264 16 – 176 6 0 1 — CC: Data Entry MSB
178265 16 – 176 38 2 1 — CC: Data Entry LSB
178653 16 – 176 99 0 1 — CC: NRPN MSB
178654 16 – 176 98 3 1 — CC: NRPN LSB
178654 16 – 176 6 0 1 — CC: Data Entry MSB
178655 16 – 176 38 3 1 — CC: Data Entry LSB
178777 16 – 176 99 0 1 — CC: NRPN MSB
178778 16 – 176 98 3 1 — CC: NRPN LSB
178778 16 – 176 6 0 1 — CC: Data Entry MSB
178779 16 – 176 38 4 1 — CC: Data Entry LSB
179599 16 – 176 99 0 1 — CC: NRPN MSB
179600 16 – 176 98 3 1 — CC: NRPN LSB
179600 16 – 176 6 0 1 — CC: Data Entry MSB
179601 16 – 176 38 5 1 — CC: Data Entry LSB

OK, this is what I got for NRPN 3 in MIDI-OX. Used abs-14 bit. annnnnnnnnnnnnnnd it works now.

#4

whoops on the formatting. Lemme try this:

[code]
TIMESTAMP IN PORT STATUS DATA1 DATA2 CHAN NOTE EVENT
655343 16 – 176 99 0 1 — CC: NRPN MSB
655344 16 – 176 98 3 1 — CC: NRPN LSB
655345 16 – 176 6 0 1 — CC: Data Entry MSB
655346 16 – 176 38 1 1 — CC: Data Entry LSB
661227 16 – 176 99 0 1 — CC: NRPN MSB
661228 16 – 176 98 3 1 — CC: NRPN LSB
661229 16 – 176 6 0 1 — CC: Data Entry MSB
661229 16 – 176 38 2 1 — CC: Data Entry LSB
661925 16 – 176 99 0 1 — CC: NRPN MSB
661926 16 – 176 98 3 1 — CC: NRPN LSB
661926 16 – 176 6 0 1 — CC: Data Entry MSB
661927 16 – 176 38 3 1 — CC: Data Entry LSB
662049 16 – 176 99 0 1 — CC: NRPN MSB
662050 16 – 176 98 3 1 — CC: NRPN LSB
662050 16 – 176 6 0 1 — CC: Data Entry MSB
662052 16 – 176 38 4 1 — CC: Data Entry LSB
662788 16 – 176 99 0 1 — CC: NRPN MSB
662789 16 – 176 98 3 1 — CC: NRPN LSB
662789 16 – 176 6 0 1 — CC: Data Entry MSB
662790 16 – 176 38 5 1 — CC: Data Entry LSB
[/code]

Maybe someone will find this helpful. I’m hoping I can get these negative NRPN’s to work as well… is it possible that when I was trying to program it, i kept sending the synth junk data at which point it would crash and even if I had discovered the proper settings I wouldn’t have known?

#5

So what’s going on with oscillator shapes above their default parameter?! Sounds cool, I get a little “!” in the upper right-hand side, and seems to work (display gets sluggish) up until #19 where it seems to crash…

#6

easter egg? actually did anyone find that yet?

#7

i’m thinking probably no… This seems more like it’s interpreting the NRPN value somehow, like it points to a memory address for the waveorm or something, cause it seems to just display erratic behavior – for example, the menu will change, parameter updates like running LFOs and such start to slow down… It’s definitely doing something it wasn’t “supposed” to do… Though I imagine there might be something hidden there…i thought i remember seeing somewhere (maybe in the source) that the little “!” was supposed to show if it was running too slowly… Come to think of it, the source wouldd be an awfully good place to hunt for eggs.

#8

I will have a look at the dump to confirm… But if it works, good…

I was thinking of changing the way the NRPN works… For the moment it’s pretty much directly writing into the patch memory, with the parameter number being the address, the parameter value being the value to write at this address (so 2 messages for values above 255, and the ability to screw things up when parameters should stay in a small range).

What I’m thinking is, instead, use the same scaling procedure as with the pos - 0 for the value you get with the pots turned on the left ; 127 (16383?) for the value you get with the pots turned on the right. The good: no need to worry about signedness and out of range values. The bad: no exploration with out of range values, and a loss of resolution for some parameters.

What do you think?

“!” means that the CPU can’t keep up with the expected sample rate and starts dropping samples.

#9

cant do negative values too…

#10

Hmm, hard to say… I guess I’d have a better answer for you when I get my controller programmed. But we’re talking about tempo and the “step sequencer” functions, right? Those are the only ones I see having a > 7 bit resolution.

tempo is a pretty important one. If you’re doing MIDI control, however, there’s a chance that you’ll just be able to clock it externally.

Another opportunity would be to implement an additional NRPN control to increment/decrement the tempo so you could have tempo up/down control in addition to the coarse 7-bit control.

I don’t understand what the step sequencer NRPN’s are supposed to be doing. In the physical interface, you get values from 0 to F… Now are we getting a full 8-bit range for each step in the pattern? If we’re talking about the difference between a range of 127 and 256 for the step sequencer, I personally think this is a small compromise.

One last comment: My bcr-2000 has rotary encoders. If you were to scale between 0-16,383 (2 words) rather than 0-127 it would take forevvvvvvvvvvvvver to actually get through the range of values. So for that specific example (and I’m guessing a lot of other controllers) that would definitely be the wrong path to take…

#11

For the step sequencer, there are 8 parameters, each of them addressing 2 steps (1 nibble for the even-numbered steps, 1 nibble for the odd-numbered steps) - so you really need to write to the 0-255 range. Again, the NRPN is really a POKE in the patch memory :slight_smile:

#12

Yeah… I can understand how this is the quick & efficient way to do it… And it could be useful for developing an external control app, but it doesn’t seem to be useful at all from a standalone controller perspective, unfortunately…