Hi there!
I just wanted to ask if Rack 1.0 will have the option of 14 bit midi control or just regular midi?
I ask because I think I read something from Andrew a while ago saying it will have 14 bit midi, and I’m thinking about building a 10 bit midi controller (10 bit because arduino can’t handle more and it’s enough for a potentiometer to just be able to hit one of the 1024 steps exactly… more is not neccessary for a simple poti knob, and poti knobs make most sense to me). Actually I have even built one already, but the readout is not stable enough yet… right now I’m thinking about it again and ask myself if it would be worthwhile to give it another try… and I think the biggest factor for me is if Rack will get 14 bit midi or not.
If it will get 14 bit midi I can try again with a single module and built a true modular controller from there… which might be really nice. At least I will make some plans about that if it is confirmed that 14 bit midi will be an option in 1.0, for regular 7 bit midi I would just take some generic controller…
Not planned for Rack 1.0 but maybe in a later 1.x release.
Thank you for the reply!
Right now I’m thinking about getting a nice joystick like this one https://www.ebay.de/itm/360-2-axis-Sealing-10K-Joystick-Potentiometer-Wont-Reset-for-Lighting-Console/263806908413 and have another go at it… if I’m successful maybe I will bother you again in a few months… 
I can add to Rack 1.0 if you answer some questions.
- 14-bit MIDI controllers send a CC value c=0 to 63 representing the upper 7 bits and then a CC value c+64 representing the lower 7 bits, correct?
- MIDI-CV would need a 14-bit mode with a context menu item, right? Have any DAWs transparently supported this?
- If so, can you describe the algorithm outline?
- If not, do they disable the actual CC values 64-127? If not, how do they handle it?
Oh wow, this is very kind of you, thank you!
14-bit MIDI actually just uses two midi CC for one control, the standard is to have CC 0-31 send the MSB (Most Significant Bit) and CC 32-63 send the LSB (Least Significant Bit). So you’re assumption is not correct - you can’t get a higher resolution out of the 7 bit CC itself. Instead it goes 1 step on the MSB and 128 (or 0-127) steps on the LSB, then another step on the MSB and another 128 on the LSB and so on… I think it would be best to just have the option of assigning a second CC to the same control to increase the resolution, the first CC would act like always and the second one would be a very fine (upwards) adjustment of that value.
I think most DAWs still don’t support this, I have Cubase and FL Studio which both have no options for it. I can however combine two CC receiving knobs in Reaktor and get a 14 bit value out of that to control a synth… in my experiments I used the 10 bit values of the Arduino to get the full MSB, which can always be used as the regular 7-bit MIDI, and the additional LSB in 8 steps (0-16-32-…), so in practice I can receive values from 0 to 1023 from a single poti connected to an arduino, which is imo exactly enough for a poti to feel analogue (you can still hit an exact value, but only veeery carefully)
If you have Reaktor 6, you can have a quick look at the attachment, which is the simple solution for 14-bit MIDI in Reaktor - it has two knobs for two CC, combined into one 14 bit value, and then a third knob for controlling the same value with the mouse - I hide the two knobs on panel B and leave one on Panel A, which moves according to the MSB to give me visual representation.
Reaktor 14 bit midi knob.zip (142.4 KB)
Ableton 10 supports 14-bit MIDI under the hood and it’s been utilised well in the following Max for Live addon. Not sure if you know anything about Max Andrew but it’s worth having a poke around in the patch as the methodology is relatively clear (as long as you don’t mind digging into nested sub-patchers).
I’m a fan of the UX too as it doesn’t over-promise and is stackable beyond 8 controller values.
BTW, it’s worth reading the PDF manual that’s linked on the Max for Live library page for NRPN Gen 2. It’s especially useful with regard to Ableton specific idiosyncracies - something which I’m sure is a similar situation with other DAW’s although the specific idiosyncracies may be different.
In truth, DAW 14-bit MIDI support is a mess. They get away with it because plugin automation uses high resolution floating point values. However, I believe high-resolution control values are even more important when bridging between virtual modular and DAW as scaling back CV’s to 128 values pretty much defeats the power of CV’s in the first place. This is another reason that a VST/AU version of Rack is an important long term goal. It will enable VCV to circumnavigate the clusterfest of 14-bit MIDI and plug directly into the floating point resolution of DAW automation.
NRPN 2 is perfect for hooking Ableton 10 up to hardware and even IOS synths like Moog’s Model 15, Model D & Animoog. I’m hoping something similar is possible in VCV, even if fully-realised 14-bit MIDI is out of scope for v1. As for VCV v2, hopefully MIDI 2.0 will provide a united approach for high-resolution control values across hardware and software.
Oh, so they aren’t CC messages at all? Looks like there are 2^{14} possible RPN numbers and 2^{14} possible NRPN numbers, instead of the 127 CC numbers.
I’ll pass for now, since it would require UI effort to allow selection of CC, RPN, and NRPN numbers. Would be more than an hour of my time, so not worth it.
Forget the NRPN stuff for now, just regular CC with a second regular CC for fine adjustment for regular 14-bit MIDI would be all I need… the 128 regular CC’s of one channel already yield 64 14-bit controls.
It would however require the option to select a second CC for the fine adjustment in the UI and have both CC’s converted into one high resolution control.
I don’t know how much effort this would require since I’m not a coder, but I don’t want to get in the way of your development process, so I guess I’m back to maybe I’ll ask again in a few months…
I’m confused on the standard then. Could you write the hex code for the two MIDI messages required to give CC 31 a value of 2^14 - 1?
The controlled knob or parameter needs to react to two MIDI CCs. You would need to be able to assign two CCs, one for the MSB and one for the LSB. Just like I wrote above and showed on the screenshot.
Edit: The standard for this would be that they are 32 CC numbers apart, so it might be enough to check a box in the UI that says “14bit” and have it assign the 32nd next CC to the LSB automatically. I guess this is what you mean. - I don’t know the hex codes but it would be the same as two separate MIDI CC messages, no additional data is needed.
You would take the value of for example CC 0, multiply it by 128, add the value of CC 32 and divide everything by 16384 to get an output from 0-1 in 16384 steps - or divide by 128 to get an output from 0-127 (or actually 0-127.99212598… because the LSB is added on top of the MSB so it would just be missing the last 1/128 to reach a full 128) in the same 16384 steps, which might be the easiest because it could happen in front of any further conversion of the MIDI signal. (maybe because of the almost 128 it would need an extra step to get it to 0-127 - but I guess you convert it into a 0-1 or 10 volts or whatever anyway)
To go with your example of selecting CC 31 as 14-bit MIDI control, it would then automatically assign CC 63 to the LSB
And with NRPNs it should be the same, you would still need two of those to assign them to MSB and LSB, only that you have more of them available.
Edit again: Sorry, maybe my first answer further up was confusing, so just to clarify again:
14-bit MIDI standard means two CCs that are 32 numbers apart, one sends the MSB the other sends the LSB, both in their regular 128 steps of 0-127.
So if you assign a 14-bit knob with CC 0 it would automatically assign CC 32 to the LSB. Then, when you turn it starting from 0, it sends 0-127 on CC 32, then 1 on CC 0 and again 0-127 on CC 32, then 2 on CC0 and so on. So it’s not one continuous value that is sent, but it sends (0) - (0-127), (1) - (0-127), (2) - (0-127), (3) - (0-127) and so on until (127) - (0-127).
quite a few edits there… I tried to make it clear and easy to get back to… I think now you can read it…
If you have an Arduino with a potentiometer nearby I could send you a short and easy code to make it send 14-bit MIDI in a step resolution of 10 bits and if you have Reaktor 6 I could send you something to enjoy the analogue feeling of that control, let me know if that would help.
Okay, some questions:
- What is the proper name for this feature? “14-bit mode”?
- Do all 14-bit controllers use only CC numbers less than 32?
- Do all 14-bit controllers only send 14-bit CCs when switched to that mode? Or do some controllers have a mix of 7-bit and 14-bit CC controls?
Now these are actually some tough questions…
I assume that the controllers who have it are able to send a mix of 7-bit and 14-bit (often moving the 14-bit ones to NRPNs), I think that it would be within that same standard to continue from CC number 64 on to 95 (which is what I did with my controller), or even to just pick any CCs that are 32 numbers apart, and “14-bit mode” sounds like a proper name to me
But it seems like there’s actually not much 14-bit controlling going on in the real world and not many controllers that support it.
Nonetheless I think it might be really good for Rack, since many modules have controls that would benefit from high resolution control and could easily be recreated as controllers with an arduino or some MIDI-board. Not many people will be able to use it, but probably more in the Rack community than anywhere else…
I will google some more, and if I find definitive answers to these questions I will post them.
Two issues I’d need to address are
- There is some time \Delta t between the CC and CC+32 messages. If I can’t assume that all CC messages are guaranteed to send both messages (because some are 7-bit), I can’t wait on CC+32 after receiving CC. I have to set the upper 7-bits immediately. This would result in non-monotonic jitter as you monotonically increase the value of the controller.
- Enabling 14-bit mode would prevent CC 32-63 from being used at all. If any 7-bit controls use CC 32-63, the user would find them nonfunctional.
I think in this instance you can safely assume that users wanting to take advantage of 14-bit mode will in the main be aware of the compromises, but those compromises only affect a single MIDI channel for each 14-bit instance.
In the DAW world the likes of the Push controller and Launchpad Pro circumnavigate 14-bit MIDI altogether as this is easier when controlling plugin automation (or native DAW instruments/effects). The core use case for 14-bit is still control over certain hardware synths and modules. Once VCV is available as a DAW plugin, artists will be able to take advantage of high resolution without 14-bit MIDI too. Much as I’d like to see a short term v1 solution, I can understand that the effort may be too much for a short term gain. Add in the fact of MIDI standards being in flux and that compounds the case against a short term solution.
Just throwing this in on the off chance it’s worth investigating further. It might be worth approaching NativeKontrol. It’s run by a very approachable chap (Sam ‘Stray’ Hurley) who does a lot bespoke work for artists (major as well as indie) and manufacturers like Akai and Novation. He’s best known for his range of scripts for a range of controllers including those from Akai, Livid Instruments, Novation, Korg, Native Instruments and Ableton. I personally use his Arsenal scripts with Ableton (for a range of midi controllers). He might be able to suggest other ways providing a high resolution interface between VCV and the outside world (both software and hardware).
There is some time Δt between the CC and CC+32 messages…
When building my controller, I made it so that it always sends both MSB and LSB every time the readout value from the poti changes. I didn’t think about jittering, but did this so that I could always use it as a regular 7-bit control and easily assign it via MIDI-learn, because it would always send the MSB first. I don’t know, but it seems logical to me that commercial 14-bit controllers would do the same thing, because it would pretty much solve the problem of jittering without having to wait for the LSB, right?
Enabling 14-bit mode would prevent CC 32-63 from being used at all. If any 7-bit controls use CC 32-63, the user would find them nonfunctional.
Think about it the other way: When enabling 14-bit control you can use two knobs of a regular 7-bit controller and have one for coarse and one for fine control - very useful for oscillator tuning and other relevant tasks.
“It’s not a bug - it’s a feature!” 
Regardless, there is always time between two MIDI messages. Depending on when they’re buffered by the hardware or software, they could end up happening at different sample frames in Rack’s engine. You can never assume two messages are processed by software in the same sample rate or block.