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.
1 Like
And it shouldn’t prevent any CC’s from being used, it should just assign a second CC 32 numbers apart to the 14 bit control, so everything else can still be mapped as usual
Regardless, there is always time between two MIDI messages.
You’re right, this might be a problem… I had an error in my logic - it would actually make sense to send the LSB first to keep the jitter to a minimum…
Same problem. LSB first would give approx the same amount of jitter.
yes you’re right… stupid thought, sorry… damn…
Would your regular MIDI solution involve smoothing? Maybe smoothing is the solution, MIDI is still pretty fast I think so a reasonable amount of smoothing might be enough?
ah… i guess it would still jitter but only smoother hm…
I’m sorry, it’s late here…
You can try it with Rack 0.6. Quickly moving CC controls is perfectly fine. It doesn’t sound quantized at all. It only does when you’re trying to fine-tune the CC control. 14-bit would solve this problem.
However, smoothing certainly would solve the jitter issue. But not in the “right” way. I’d rather wait on LSB.
1 Like
Waiting for it is probably the only good solution, this would prevent the “feature” of using two controls of a regular 7-bit controller and all controls would have to be 14 bit, since you probably don’t want to make it an option per control but just one checkbox for all controls… this would still be fine with me but to be able to use both would of course be better… I think this might only be possible by being able to enable it for each control individually.
Okay, if we can agree with that, that’s what I’ll do.
1 Like
Yayyy!!!
That’s very cool! I hope some other people will be as happy about this as me!
So I get that this means I can start building my first module. Very very very cool! 
1 Like
I hope I did get you right and didn’t rush you there, you meant waiting for the LSB not waiting with it altogether, right?
But you know what? I think I just had a change of mind and don’t care too much about it any more… building a 14 bit controller is a bit tricky since the readout of a poti already gets very sensitive in my desired 10 bit resolution. For example: just moving my hand near a cable makes the readout jump, the usb power output of my laptop seems to be too noisy and so on… but what finally changed my mind was playing around with your latest dev build for a few seconds, so I realised stepped 7 bit midi might actually be to my advantage when tuning an oscillator, since it works in semitones now.
So if it’s just for me I think you can forget it for now, and when (/if) MIDI 2.0 comes there will probably be a resolution for higher resolution.
If you still want to integrate 14bit MIDI I will still try to get at least a few controls in high resolution, but I will also be happy with the regular implementation and it will already make Rack really a lot of fun for me.
Right now I’m in the final steps of planning my dedicated Rack controller, the last parts should arrive within the next few days and it will be sooooo nice to play around with it…
Sorry for bothering and thank you a lot for considering requests like this!
If you still want to implement it please let me know, and if it is important to anyone else please tell in this thread.