How do I use NRPN to Control Plugins?

I just read your very detailed set of steps. I am unable to test this right now but I am entirely grateful for your effort to try to assist me with this! Thank you VERY much for your time.

 

I will try to get to this before another nine months fly by!

Slightly off topic but related...

 

Just read an article about midi 2.0 that might be of interest. Also, I once a was interested in a Euphonix (now Avid) control surface that used a network protocol and had a 1000 (or something like that) steps (as opposed to 127). Different means, but achieve the same ends, out of the box...

Slightly off topic but related...

 

Just read an article about midi 2.0 that might be of interest. Also, I once a was interested in a Euphonix (now Avid) control surface that used a network protocol and had a 1000 (or something like that) steps (as opposed to 127). Different means, but achieve the same ends, out of the box...

 

I’ve been waiting for MIDI 2.0 to become a thing for ages. It’s currently in prototyping stage, if I recall correctly (with which developers and hardware companies I have no idea).

 

The Euphonix gear... I kept an eye on it for a time, but it is mostly just typical mixer/shuttle/DAW control surface stuff, and it was always fairly expensive and I’ve seen people express considerable frustration with the execution and stability of the software/drivers, etc.

 

The 1000 steps in that case is probably no different from the Mackie control surface clone I have. You can get those steps on the infinite encoders, but it’s at the cost of turning the knobs a lot more. It’s not higher resolution in the same throw distance. Same issue with the NI Kore controller (though the encoders on that ARE actually a bit higher resolution than typical ones... but Kore is dead).

 

I don’t think this will really get better until MIDI 2.0, and then it’ll take a long time until everything that supports MIDI 1.0 is updated for the new protocol, which will probably be as long or longer than the time it took for the MIDI Association to near-finalize 2.0 (30 years?). Hardware won’t see updates. Software... well... How long did it take for developers to move to 64-bit?

 

Since almost no one seems to notice the low resolution in the first place, there’s next to zero demand to fix it anyway.

 

Hell, the ability to travel through all 128 steps in MIDI 1.0 is bad enough on some controllers. Have you ever checked to see what the actual range of output values are that you get from a cheap to mid-price controller? My M-Audio Oxygen 25’s mod wheel jumps all over the place and the keys are so bad that the actual available velocity range is more like “nothing, nothing, 90, 127”. The convenience of the device is almost utterly defeated by the lack of subtle expression. It doesn’t have aftertouch at all.

 

The aftertouch on my Alesis (channel only) feels like you jump through all 128 steps too easily. Once again, no subtlety.

 

We mostly only get poor use of the 128 steps we have now, so I don’t imagine hardware will be suddenly (or consistently) using a wider range any time soon after MIDI 2.0 is out.

MIDI CCs are 7 bit by default. "14 bit CCs" are actually two CCs used together.

 

The MIDI spec intended CCs from 0-31 to match up with CCs 32-63. Let's choose CC#2 (breath for our example. If the breath controller sends the upper (MSB) bits as CC #2 and the lower (LSB) bits as CC #34. The receiving device must support this feature in order for it to work. Otherwise, it uses only CC#2 for breath and the result is still 7 bit resolution. If it does support 14 bits (or any number of bits between 7 and 14) it looks at CC#34 as well.

 

Xmitter resolution Rcvr resolution Final resolution

7 bit------------------7 bit-------------7 bit

7 bit------------------ 14 bit------------- 7 bit (CC#34 is assumed to be 0 by rcvr)

14 bit------------------ 7 bit------------- 7 bit (CC#34 is IGNORED by rcvr)

14 bit------------------ 14 bit------------- 14 bit

 

Whether using the two CC method or NRPNs, although max resolution is 14 bits, some devices use much less...10 or 12 bits. To our ears, 10 bits adds 8x as many steps which is often enough to make zipping/stepping inaudible.

 

NRPNS are also CCs (yeah, that is confusing). They have two parts, the two CCs (98 and 99) used to index the parameter number and the two CCs (6, 38) that carry the data. Since NRPNs are indexed by 14 bits, they allow over 15,000 parameters to be controlled vs. the 128 parameter limit of normal CCs. However, they can be slower to use since more bytes have to be sent....up to 4 for each parameter value. Once CCs 98 and 99 have been set, it is assumed that all changes to CCs 6 and 38 are for the smae parameter, So if only one parameter is being changed, then the total number of bytes sent is (2 x number of steps) + 2. If multiple parameters are changed at the smae time it can be as much as (4 x number of steps) becasue the index (CCs 98, 99) keeps changing. Over physical MIDI cables this can result in latency. Inside a DAW, not so much. because it's not limited by the 31kHz transmission rate.

 

Hope this helps.

MIDI CCs are 7 bit by default. "14 bit CCs" are actually two CCs used together.

 

The MIDI spec intended CCs from 0-31 to match up with CCs 32-63. Let's choose CC#2 (breath for our example. If the breath controller sends the upper (MSB) bits as CC #2 and the lower (LSB) bits as CC #34...

@enossified: can I just jump in here and ask you to answer a quick question about the syntax of 14-bit CCs?

 

If I wanted to send a 14-bit breath control message per your example, do I literally send CC2 immediately followed by CC34? Is it that simple?

 

Thanks if you can confirm or deny.

MIDI CCs are 7 bit by default. "14 bit CCs" are actually two CCs used together.

 

The MIDI spec intended CCs from 0-31 to match up with CCs 32-63. Let's choose CC#2 (breath for our example. If the breath controller sends the upper (MSB) bits as CC #2 and the lower (LSB) bits as CC #34. The receiving device must support this feature in order for it to work. Otherwise, it uses only CC#2 for breath and the result is still 7 bit resolution. If it does support 14 bits (or any number of bits between 7 and 14) it looks at CC#34 as well.

 

Xmitter resolution Rcvr resolution Final resolution

7 bit------------------7 bit-------------7 bit

7 bit------------------ 14 bit------------- 7 bit (CC#34 is assumed to be 0 by rcvr)

14 bit------------------ 7 bit------------- 7 bit (CC#34 is IGNORED by rcvr)

14 bit------------------ 14 bit------------- 14 bit

 

Whether using the two CC method or NRPNs, although max resolution is 14 bits, some devices use much less...10 or 12 bits. To our ears, 10 bits adds 8x as many steps which is often enough to make zipping/stepping inaudible.

 

NRPNS are also CCs (yeah, that is confusing). They have two parts, the two CCs (98 and 99) used to index the parameter number and the two CCs (6, 38) that carry the data. Since NRPNs are indexed by 14 bits, they allow over 15,000 parameters to be controlled vs. the 128 parameter limit of normal CCs. However, they can be slower to use since more bytes have to be sent....up to 4 for each parameter value. Once CCs 98 and 99 have been set, it is assumed that all changes to CCs 6 and 38 are for the smae parameter, So if only one parameter is being changed, then the total number of bytes sent is (2 x number of steps) + 2. If multiple parameters are changed at the smae time it can be as much as (4 x number of steps) becasue the index (CCs 98, 99) keeps changing. Over physical MIDI cables this can result in latency. Inside a DAW, not so much. because it's not limited by the 31kHz transmission rate.

 

Hope this helps.

 

I'm aware of the academic stuff. It's available all over the place and is the most regurgitated info whenever I ask about this subject on a forum. It's the practical execution info I have been seeking, and that info seems non-existent anywhere. The theory seems to be all that is available around the web, not the execution. Still, I need to follow the steps outlined by drb above to use Moog Model 15 to send 14-bit MIDI to Logic's ES2, which is the first time anyone has actually attempted to show any procedure for execution... but I'm also still locked into other projects at the moment. I just checked my email and saw the thread notification, so here I am for a minute... and off again.

If I wanted to send a 14-bit breath control message per your example, do I literally send CC2 immediately followed by CC34? Is it that simple?

 

Thanks if you can confirm or deny.

 

That would work but what you really need is a controller that understands 14 bit CCs and implements all this natively. Most modern Moogs like the Phatties can do this, for example. Let's say you want breath to go from 0 to 16383 (14 bits full range). Here's what happens:

 

CC2 = 0, CC34 = 0

 

CC 34 goes from 0 to 127

 

CC2 = 1, CC34 = 0

 

CC 34 goes from 0 to 127

 

CC2 = 2, CC34 = 0

 

CC 34 goes from 0 to 127

 

etc.

 

until:

 

CC2 = 127, CC34 = 0

 

CC 34 goes from 0 to 127

 

CC2 = 127, CC34 = 127

 

Done! In other words, you move the LSB (CC34 in this case) from 0 to 127, then the MSB (CC2) advances by one at the same time as the LSB reverts to 0, repeat. Reverse the order for decrementing the value.

 

Now if you try to do this manually drawing automation, sure, you can do it, but it's tedious. If you want to do this by twisting knobs, next to impossible. Let's say you have a rough value already set for CC1 you can tweak fine values by changing CC33 but only ascending!

 

What controller are you using today? Some controllers can do 14 bits but you have to dig into the manuals to see which ones can do it...most do NOT. There are a few that support 10 or 12 bits (the missing bits always get sent as 0s) which appears to be enough for most applications. 12 bits has 32 times as many steps as 7 bit, 10 bit is 8 times.

 

I have read that the Faderfox UC3/UC4, Behringer BCR/BCF2000 and some DJ controllers can send more than 7 bit CCs. Good luck in your search!

It's the practical execution info I have been seeking, and that info seems non-existent anywhere. The theory seems to be all that is available around the web, not the execution.

 

Both 14 bit CCs and NRPNs are easy to use if you have hardware that supports it. Like a Moog Phatty (CC), older Korg Electribes (NRPN), some DSI synths (NRPN). In the global menu you enable the 14 bit CCs or NRPNs and when you twist controls, the instruments send out the right messages. The CPU in the hardware does all the work of sending the messages for you.

 

You could just buy the cheapest Sub Phatty you can find to use as a controller...this would actually work as long as the receiving instrument supports 14 bit CCs. 28 of the CCs from 1 to 31 are available in 14 bits on the Sub Phatty, as long as the 3 that are missing don't include the CC you want you're good to go.

If I wanted to send a 14-bit breath control message per your example, do I literally send CC2 immediately followed by CC34? Is it that simple?

 

Thanks if you can confirm or deny.

 

That would work but what you really need is a controller that understands 14 bit CCs and implements all this natively...

Thank you for taking the time to type all that out and explain it so clearly, I really appreciate it!

That's one of those MIDI things I really should have known by now but didn't and was embarrassed, so I acted like I did, which left no one for me to ask to explain it, etc, vicious circle...

 

I have a BCR2000 that I just packed up and put into studio "long term storage" 2 weeks ago, but it looks like I'll be digging that right back out.

 

Have a great 2020!

Glad that was of help. Google "BCR2000 14 bit" and you will find lots of discussions about how it's done.

Did you solve this? I am interested as well, only because the Moog Source is using NRPN 2 for cutoff...

When using NRPN with hardware-synths you will see that the timing of MIDI-notes will be as bad as an unquantized row of 16ths played at 180 bpm...meaning if you not need it STAY AWAY from NRPN. The higher resolution thing will be useless with the unacceptable MIDI-timing due the the limited MIDI 1.0 protocol where every single event will be sent in serial meaning they will arrive late as soon as you send more than simple MIDI on offs.

It's the practical execution info I have been seeking, and that info seems non-existent anywhere. The theory seems to be all that is available around the web, not the execution.

 

Both 14 bit CCs and NRPNs are easy to use if you have hardware that supports it. Like a Moog Phatty (CC), older Korg Electribes (NRPN), some DSI synths (NRPN). In the global menu you enable the 14 bit CCs or NRPNs and when you twist controls, the instruments send out the right messages. The CPU in the hardware does all the work of sending the messages for you.

 

You could just buy the cheapest Sub Phatty you can find to use as a controller...this would actually work as long as the receiving instrument supports 14 bit CCs. 28 of the CCs from 1 to 31 are available in 14 bits on the Sub Phatty, as long as the 3 that are missing don't include the CC you want you're good to go.

 

My Korg Kontrol49 lets me choose to send CC or NRPN but I've never gotten this to work. I was confusing NRPN with 14-bit MIDI, but now I realize they're separate concepts. I have no other hardware that even remotely implies 14-bit MIDI support. That's why I was going to try to use Moog Model 15 on iPad to try it... I STILL haven't gotten around to trying this per the instructions someone posted here weeks back. I am still messing with other studio/life issues...

I´ve got a response on Gearslutz which was to use a midi plugin in reaper which worked perfectly. It is strange you just cant set up a virtual knob in Logic and assign a nrpn number to it instead of cc.

It's been a bit since anyone has touched this, but thought I would try to help clarify, even if the OP decides to light me up for offering a technical treatise. So if anyone is interested in the solution itself, skip to the last paragraph. Maybe it isn't the best solution, but it's the best process of events I thought of to solve the question, and no it isn't step-by-step and here is why:

 

It is actually important to understand the technical part and I will chime in to help others better understand it, because it isn't well documented (because it isn't a STANDARD). You can send 14-bit MIDI and it uses four CCs to do so. In the case of NRPNs it is 99/98 and 38/6. In the case of RPNs it is 101/100 and 38/6. There are also combos you could use to target certain things (see link below), but I have not implemented any of these additional settings on my own (pitch bend and bank select being popular ones from what I am told).

 

There is really no option to NOT manually input this information. You have to send two values to define the target parameter (over 99/98), whether it be in the form of an integer that is then split into two values using a bitwise AND function, and bit shifting (ex. 218 translates to [1, 90], 2682 equals [122, 20]), or you just send two integers over each respective channel. The same approach is to be had when assigning a value to said parameter (1st value), and also changing it (2nd value), sent over CCs 38/6, respectively. So the math is actually very important because again there is no STANDARD to these routings because every synthesizer, controller, and software plugin are different. Some synthesizers don't use both CCs 38 and 6, some just use a single CC.

 

Manufacturers of both software and hardware treat all of this differently, and the parameter routing is defined by the order of these integers. So whether you call it NRPN, RPN, "the great amazing CC combo party to send hi-def stuff", it doesn't matter; it is all assigned via bit values and not control channels (like standard MIDI messages). However you decide to frame the question, the reality remains that it's not that straightforward of a process.

 

It's also not so light in resources, which is why it isn't widely supported (or hasn't been until probably the last decade at best), and it has to do with the baud rate of data transferred over DIN connections. It is about 31250 bits per second and sending hi-resolution data would cause jams errors (which is why only choice parameters were subject to use 14-bit, like pitch bend). Now that serial ports have become better and mainstays in controllers and synthesizers (able to send 112k bps or so), these messages can be better handled. But to expect it to be a plug and play adventure like normal MIDI, and then getting pissed off at everyone for trying to explain why it doesn't work that way, isn't really cool. And the fact that you later had to ponder the clarification of NRPN vs. 14-bit resolution sort of showed that you didn't fully understand this topic and asking in such an aggressive manner is silly and just makes people feel bad.

 

For your solution, I am fairly certain that Logic Pro supports 14-bit MIDI (I have read that it does, but I have never done it, so I say "fairly certain" (see link below)), but it is up to the manufacturer of the VST to support 14-bit messages directly. And it doesn't seem like a lot of them do, because any detailed automation or control you might need could be done directly in Logic itself. So my suggestion would be to route your Korg NRPNs to the channel strip in Logic with the plugin, assign the channel values to the parameters in your plugin, and then you're good. Yes you have to MANUALLY do stuff, if that is your hangup, then you aren't going to get very far. It'll take some time, but once you get it mapped, then you don't have to mess with it again and you can use that same channel strip setting to route your controllers to your plugins as needed. Or whatever you want to do.

 

I hope this helps someone out!

 

 

https://www.midi.org/specifications/item/table-3-control-change-messages-data-bytes-2

viewtopic.php?t=81147

You can send 14-bit MIDI and it uses four CCs to do so ... I hope this helps someone out!

This helps me out. I've never really needed or wanted to use 14-bit MIDI, but not knowing *how* to do it was driving me nuts and I was embarrassed to ask publicly.

 

Oops, guess I just outed myself. But at least now I know.