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.
14bit NRPN midi in v1, yes please
FYI, here’s some arduino code that sends NRPN https://github.com/bastl-instruments/60Knobs/blob/master/Firmware/functions.ino
They sell a DIY kit with 60 knobs - knob resolution 10bit (ATMega328 analog in)
The 60 knobs looks nice!
I think NRPN would not be neccessary and it has advantages to send regular MIDI RPN, like being able to still use the MSB of the 14 bit control as a regular 7 bit control.
10 bit control with an arduino is really nice, but unfortunately very sensitive to noise… I hope I can get stable readings on the controller I want to build for Rack… if not it will just be a 7 bit controller… will see.
I’m putting a 100nF capacitor from the middle pin to ground on the pots (10k ohm) - this should remove some noise.
I’m planning on putting some smoothing in the code, using this library:
I will be using a 16 bit 4 input i2c ADC converter to the arduino to read pots - ADS1115
For multiplexing 16:1 - 74HC4067 mux - arduino library here:
Rotary encoders will be read using MCP23017’s
I plan on making a box with 64 pots and 8 rotary encoders with push switch function. Components ordered and in transit.
Some useful info on NRPN here:
1 Like
That sounds good!
I might get me this converter, too, maybe it solves the issues.
I also tried with a Teensy, which was supposed to give me better resolution, but it was about exactly the same as with an Arduino nano (clone). And I made the mistake of not soldering everything and also putting a few RGB-LEDs in it, which I controlled with PWM, which also disturbed the signal a bit.
This time I got me 1k potis, in hope that the signal from them is a bit stronger.
And if nothing else helps it might be a solution to get a separate power supply with low noise.
I hope I can manage to build it soon and wish you great success with yours!
my newest update:
My controller is almost finished, with smoothing I can get stable 10 bit values without capacitors or external power supply on an Arduino Nano V3 clone.
Only the highest values can not be reached sometimes, a bit of that is due to the smoothing, another bit probably the potis themselves?.. so I get good values from 0 to 1010 or something like that.
just one more, possibly last update:
I have a finished a controller with 64 knobs now, soldered to 8 multiplexers, soldered to an Arduino Nano V3 clone. from the 64 knobs at least 15 don’t work, some not at all, some only in one half of their range… My only explanation is that either the multiplexers or the potis themselves are broken, but I don’t have the nerves now to take everything apart again… maybe I can still fix it but for now it’s just a desaster.
@ jpn9900 please tell me how it went for you when you’re ready to say anything about it.
For decades I have not understood how 14 bit MIDI is “supposed” to work. When the value goes from (for example) 03,7f to 04,00 how do you interpret it to avoid jumps? If the lsb changes first, you will see 037f -> 0300 -> 0400. If the msb changes first you will get 037f -> 047f -> 0400. How does it work?
All of the encoder-based controllers I have, or know about, that can send 14-bit MIDI CCs or NRPNs (which isn’t that many) also support sending “relative mode” CCs.
I think relative CCs would be a much more useful thing for Rack’s MIDI mapping to support. They’re still present on modern controllers like the APC40mk2. Unfortunately there are several different practices for how motion gets encoded in the 7-bit CC value.
I haven’t really thought about that before, but as Andrew pointed out somewhere above, the software that receives the messages should wait for both MSB and LSB to arrive.
I was hoping to get something with super sensitive knobs ready by now, but from how it looks it doesn’t look too good for me. So it might be that there is not even a single person who really could use 14 bit MIDI right now… I have a BCR2000 which can send 14 bit, but it’s not really fun to use with the encoders… I guess I’ll just have to add an extra module here and there to add “fine” controls to something like the Macro Oscillator 2 for example.
I hope that pitches on Oscillators and Filters will be stepped in semitones with MIDI control, and that bi-directional knobs center nicely… then I will be fine with some standard controllers.
yes, but I’m pretty sure some hardware synths send only the lsb when it’s not “necessary” to send both. I used to bring this up at every MMA (MIDI Manufacturer’s Association) meeting, but people didn’t seem to get it. But it’s really never been fully specified as far as I know.