Loopy Pro: Create music, your way.
What is Loopy Pro? — Loopy Pro is a powerful, flexible, and intuitive live looper, sampler, clip launcher and DAW for iPhone and iPad. At its core, it allows you to record and layer sounds in real-time to create complex musical arrangements. But it doesn’t stop there—Loopy Pro offers advanced tools to customize your workflow, build dynamic performance setups, and create a seamless connection between instruments, effects, and external gear.
Use it for live looping, sequencing, arranging, mixing, and much more. Whether you're a live performer, a producer, or just experimenting with sound, Loopy Pro helps you take control of your creative process.
Download on the App StoreLoopy Pro is your all-in-one musical toolkit. Try it for free today.
(N)RPNs -- How to best display their values in a sequencer?
I was wondering if any of you regularly use (N)RPNs (probably particularly with hardware) and how you prefer your DAW / sequencer of choice to display (and let you edit) their values -- especially with 14-bit (LSB in use) ones.
There's many options I can think of (and have seen). Let's use an example of MSB = 2 and LSB = 3:
1) Simply act as if MSB and LSB were a single 14-bit value, so: MSB * 128 + LSB = 259
2) Treat each 7-bit word as 8-bits: MSB * 256 + LSB = 515
3) Display MSB and LSB separately: 2 | 3
While to me, option 3) looks like the most flexible, it of course creates problems when you want to draw smooth automation or anything.
How does existing software do this? Do they offer multiple options depending on each (N)RPN's use case?
Example 1: RPN 0 (Pitch Bend Range) uses MSB for Semitones and LSB for Cents. So, only option 3) would make sense for this RPN.
Example 2: You have a synth that uses a 14-bit NRPN for one of its knobs. Here, only option 1) would make sense to display (and edit) a single continuous, sensible value.
Comments
I feel like I've created a topic about serial killers or so...
😁
I've just discovered your question - threads can slip away really fast here.
The way Drambo does it with pitch bend (also a 14bit value): Show only the MSB but keep the precision intact.
I think the answer is in how people are going to use RPN and NRPNs.
One knob for the 14bit value might work if you do something like Drambo does: Vertical adjustments (coarse) change the MSB, horizontal adjustments (fine) change the LSB.
For editing single automation points, a dialog with two large enough knobs or long enough sliders plus numerical display should work.
Edit: Maybe you can introduce a settings page where the user can define his custom (N)RPNs including his preferred way to edit them.
Oh, I had actually overlooked your answer
but no worries, I've opened another thread on a related topic already that will get 0 replies 
The way I've implemented this for now is that in most places (sliders, etc.), only the 14-bit value is displayed. However, as soon as there's a selection in the controller editor, 3 values are displayed -- 14-bit, LSB and MSB, and can be edited separately:
Tapping a value button pops up a menu which lets you select which part of the 14-bit value you want to edit, or the whole 14-bit value:
Tapping on one of the buttons pops up a number entry dialog.
Looks like an OK compromise between implementation work and usability for now.
Yer all talking alien to me
I have at least one gear (I think the MC-303 - but maybe also the Electribes) which needs NRPN, but may be lazy or can't just understand the topic
For me it seems to make sense option 3 - Showing MSB and LSB separate.
Would making it interchangeable in the preferences possible, or would just add too much coding? (I know these things can do more damage then help sometimes
)
Edit: Nevermind. The way you show single value and cand edit it separetely is badass awesome
(N)RPNs are essentially just another (huge) set of controllers in addition to the (roughly) 128 "standard" controllers available in MIDI. There's 16384 of them and another benefit is that they all have 14-bit precision (in contrast to "standard" controllers where you can only have 32 14-bit controllers)
It's very obvious after my multiple threads on the topic that it's something that's not widely used -- but I wanted to look into supporting them in Xequence anyway.
Unfortunately, implementations seem to vary widely and the MIDI standard isn't very accurate on how to handle edge cases (see my other thread from today) or I'm not finding the relevant information.
Looking good. Single slider "with benefits" seems the way to go.
I could see two concurrent sliders (MSB/LSB) being an interesting way to interact live with a 14bit control value on smaller surfaces (anything with a short 'throw', so to speak). That way, you could use one finger for course/close-enough and another for fine tuning. I'd probably want the LSB to be a center-based slider though so that it always acted like an offset amount for the MSB.
Hmmm... I'd rather implement that as a general modifier for all sliders (a la "put second finger on surface to decrease sensitivity to 10%" or so)... that way you wouldn't be limited to artificial 0..127 LSB intervals and it could be used for all sliders in Xequence.
@SevenSystems Your suggestion looks great, being able to draw a curve as well as editing singular values looks like a workable solution. 👍🏼
I think it really depends on what the device expects. If it really treats the two values as a single value (which I suspect is the most common) then having to use two sliders to send the value would be problematic.
Elektronaut Olaf has taken the time to put together a very nice overview:
https://www.elektronauts.com/t/nrpn-tutorial-how-to/46669
I would not treat his explanation as definitive -- as someone points out on that thread: much depends on the actual hardware you are talking to. Some time ago, I looked into this and what I found at that time was that there is some variation in how different devices deal with these. While the spec suggests that two bytes be treated as 'coarse' and 'fine' settings, it seems like it is more common for them to be treated as a single value with both bytes always being sent.
The impression that I had is that old hardware was more likely to treat the values 'per the spec' and that more recent devices were likely to treat the NRPN bytes as being a single 14-bit value.
In my mind anyway, the first slider would always send values at the highest resolution possible for the the throw available. The second would only be used as an offset.