Sending NRPN Limitations

I did a search for other NRPN posts but I didn’t find this particular topic anywhere. I am looking at the UI for sending NRPN values on the OG DT and I am just a tad bit mystified why we need to “waste” two of the knobs on something we’re VERY unlikely to ever want to modify “live” as it were, namely the “destination” of the NRPN.

Seems to me it would be better (albeit extra work, I get it) to allow setting whether a knob is CC or NRPN on the AMP screen. Then for CC knobs everything stays as it was, but for NRPN knobs one can choose whether to use a single knob for the entire range (either 7 or 14 bit) or two knobs next to each other (AB, CD, ED, GH) in “MSB, LSB” mode. Also configure the “destination” for the NRPN in a popup or something similar to the “retrig” popup.

With many synths, the DT quickly “runs out of knobs” for doing NRPN. On my old AKAI for example I could in theory control filter frequency, resonance, and envelope ADR via 8-bit NRPNs. Right now I can control at most two of these five. With a different UI it could be all five and a few more.

I doubt whether there’s interest on Elektron’s side to do this for the old DT I have here, but maybe they could consider it for the new one?

maybe, i personally doubt that’s something they’d want to work in preset complexity for due to the limited payoff for doing so and because it’s in essence focussed beyond the unit … albeit adding niche flexibility to the user

Why stop there, get a sysex string creator which computes a checksum before sending or advanced macros where you specify the range and labels and so on

Basically i think it’s unlikely, but that’s no obstacle to submitting the idea on the Feature Request topic *this is a feature request, it’s not revealing fundamental limitations, they just don’t expect people to be hacking out NRPN strings as it’s so cumbersome

The reason they provide NRPN compatibility for their parameters is legit, i don’t know if it’s too niche to expect them to ease the burden of using the device as it probably wasn’t intended, but it could be handy, make a Feature Request here or ideally send direct to Elektron using the email at the top of the FR topic … you never know, it’s doable if there’s a desire, but it feels niche to me even though i’d use it on occasion

I imagine, they might expect users with this need to do something via a MIDI translator so you don’t need to provide the destination pair within the Elektron, but it’s still clunky for many parameters

1 Like

Considering how much support Elektron devices have for receiving HRCC/NRPN control, I agree that it would be great if there was also a way to properly configure them to send HRCC/NRPN values to MIDI devices.

HRCC/NRPN control is mainly about accessing the full precision of the receiving device.
Every parameter on an Elektron device which uses decimals has more than the 7-bit precision CCs offer.

I don’t think supporting that is adding too much complexity, or is too much to ask for.
It’s certainly not in the same realm as SYSEX commands.

HRCC/NRPN is only combining two 7-bit CC values to create a single 14-bit control.

(NRPN technically transmits four values, while HRCC only needs two - so the latter is preferred to save bandwidth)

1 Like

I understand how it works, I have made NRPN and Sysex controllers, in fact some Elektron parameters are using a 2s complement scheme to define an extended range. My point was that it’s one thing to see and understand the potential but it’s another thing to implement robustly and justify the time taken to do so. Some manufacturers utilize a different order for their nprn strings, flipping most with least so you need a way to handle that if you’re sending a combined value. It’s also a slippy slope because soon people will want to be defining the minimum and maximum values or step intervals etc. anyway that’s just my thoughts on the matter, I’d support the future request, but wouldn’t hold my breath !

1 Like

Particular case (not high resolution) but I used NRPN to control Euclidean sequencer…midi loopback of course.