14 bit midi in 1.0?

Not so, according to Haken Audio:

The Midi spec explicitly states:

The MSB/LSB pair can be sent in either order (MSB first or LSB first).

It is permissible to send only MSB or only LSB.

The consequence of this is that a receiving synth immediately uses MSB values as they arrive, and LSB values as they arrive. Since the high 7 bits and the low 7 bits are not updated synchronously, this will always create intermediate glitch values. For example, updating from 14-bit controller value 0x137f to value 0x1401 always creates one of these two intermediate glitch values: 0x147f or 0x1301. This means the values have been reduced to 6 bits of accuracy (down from the normal Midi 7 bits) by using Midi 14-bit controllers! MPE+ solves this problem with synchronous 14-bit updates.

In addition to resolving the glitch problem, MPE+ explicitly allows the controller to switch between 7-bit and 14-bit encoding simply by skipping the LSB. To achieve this, MPE+ encodes the MSB the same way (channel pressure) for 14-bit control as for 7-bit control, and the max value for 14-bit controllers is 0x3f80 (not 0x3fff).

Nowhere in the standard does it say that. It does say

If 128 steps of resolution is sufficient the second byte (LSB) of the data value can be omitted. If both the MSB and LSB are sent initially, a subsequent fine adjustment only requires the sending of the LSB. The MSB does not have to be retransmitted. If a subsequent major adjustment is necessary the MSB must be transmitted again. When an MSB is received, the receiver should set its concept of the LSB to zero.

The last sentence indirectly implies that MSB CC messages must be sent before LSB, because otherwise the LSB would always be set to 0.

OK, I think I get it. except there seems to be a discrepancy. You are saying (I think) that when you get an MSB you don’t act on it until you get the LSB that goes along with it. That sounds like a protocol that will actually work. But it directly conflicts with the line from the standard that you quoted: “When an MSB is received, the receiver should set its concept of the LSB to zero”. So the spec says that when you get an MSB you act on it immediately, assuming LSB 0, and you say don’t act on MSB.

What you say makes, but (I think) the spec has always been wrong.

I understand what you’re saying, but if you interpret the standard as what to do if you don’t care about the MSB/LSB intermediate jitter problem, then it does in fact imply that a CC change must be MSB first and then LSB. Applying this implication to the fixed jitter problem means that you must store MSB in your temporary memory and wait on LSB before actually changing the final 14-bit value. This fix requires the user to actively enable “14-bit MSB/LSB mode” because of course if not using a 14-bit MIDI controller, LSB will never arrive and thus your final value won’t ever be updated.

yes, I agree that your interpretation is the only one that makes sense. I’m sure we would both be surprised if everyone who sends 14 bit midi CC does it that way. But in any case I applaud your solution.

Hello,

I’m Christophe from Haken audio. We received a mail about this discussion and you are right it deserve some explanation (and probably a sentence rewriting on our web site).

The sentence " The MSB/LSB pair can be sent in either order (MSB first or LSB first) ." is a shortcut to explain the glitches, but you are right it may be misleading. Midi says this:

If 128 steps of resolution is sufficient the second byte (LSB) of the data value can be omitted. If both the MSB and LSB are sent initially, a subsequent fine adjustment only requires the sending of the LSB. The MSB does not have to be retransmitted. If a subsequent major adjustment is necessary the MSB must be transmitted again. When an MSB is received, the receiver should set its concept of the LSB to zero.

And for a lot (but not all) of the other (non CC) 14 bits information it is LSB-first …

So what we initially wanted to point is the risk of glitches mainly due to the" When an MSB is received, the receiver should set its concept of the LSB to zero. " (if the following LSB is 126 you will definitely get a pretty “nice” glitch).

Also this extract from the MIDI spec is saying that it is mainly MSB-first, where most other uses of 14 bits are LSB-First (so you have both depending on what you do, but it is not a choice, just not fully consistent across the spec).

For NRPN, it is a bit different (but probably out of scope here):

3. After the reception of Non-Registered (or Registered) Parameter Numbers has been enabled, the receiver should wait until it receives both the LSB and MSB for a parameter number to ensure that it is operating on the correct parameter. 4. The receiver should be able to respond accordingly if the transmitter sends only an LSB or MSB to change the parameter number. However, since the transmitter can’t know when reception was enabled on the receiver which will be waiting for both the LSB and MSB (at least initially), it is recommended that the LSB and MSB be sent each time a new parameter number is selected.

The sentence " It is permissible to send only MSB or only LSB. " is fully true

But you are right and we will replace, " The MSB/LSB pair can be sent in either order (MSB first or LSB first). " by something like " The LSB has to be reset on MSB reception (which is possibly resulting in glitches) "

Christophe

4 Likes

Will Rack be able to send 14-bit MIDI as well as receive it? That would be great for use with MIDI-CV converters that support it, like Expert Sleepers FH-2. Here’s what the FH-2 manual says about their implementation:

A convention exists for sending 14 bit values via MIDI CCs, using two CCs (of 7 bits each).7 The high 7 bits are sent on a CC in the range 0-31, and the low 7 bits are sent on the CC numbered 32 higher (which is therefore in the range 32-63). The low 7 bits are sent first. The FH-2 configures this automatically, if – one of the three 14 bit quantities is mapped to CC in the range 0-31, and – the corresponding low bits CC is not mapped to anything else. For example, say the direct level on output 5 is mapped to CC 4 on MIDI channel 1 (as it is in the default configuration). Then CC 36 (36 being 4 + 32) on MIDI channel 1 is automatically mapped as the low 7 bits, unless that CC has been explicitly mapped to control something else. Note that this doesn’t mean you have to control these quantities with 14 bit controllers. Sending a single CC to control the mapped value will control it perfectly well, just at a coarser resolution.

No, I have not added 14-bit MIDI to VCV CV-CC. Post a feature request.

Thanks, I will.

For anyone interested in 14-bit MIDI CC:
I’ve implemented it in my MIDI-CAT module. It is not fully tested yet but feel free to check out the latest development build.

11 Likes

Very cool!

Is anyone succesfully using 14-bit MIDI?

I have to admit that my adventures in building my own MIDI-controllers were not very successfull… Arduino is too sensitive to fluctuations… I was almost able to get 10-bit (max resolution on Arduino), but quite slow, because a lot of smoothing was needed. Then I tried the Teensy (theoretically able of reading with 12-bit (they say “up to 13-bit”)), which was even worse because it’s even more sensitive… Arduino operates with 5V, Teensy with 3V… I think it might be good to have something with higher voltages so the fluctuations become negligible…

I’m no expert in electronics but I have some experience with Arduinos myself.
I guess you are reading some analog values from the microcontroller‘s analog input pins but I don’t think this is a good way to go. I think using a digital pot, a sort of encoder, and generating 14-bit values internally on controller-side would be a more suitable use-case for 14-bit MIDI.
But as I said I’m no way near an expert at this topic :slight_smile:

The dream was to have lots of knobs that feel like they’re analogue, encoders often aren’t much fun because of their low resolution and are also quite expensive.

The coolest thing would be endless analogue knobs, read out cleverly to be used like high resolution encoders - which is what I think NI did with their KOMPLETE KONTROL series.

I have a M32 and I’m sure these knobs are digital. Does something like a „endless analog knob“ even exist? I’m curious how that would work…

Don’t know… It was my conclusion because they have 128 steps in one turn and feel smooth… also got the M32 recently :slight_smile: Maybe they just have a very high resolution…

I thought it must be a potentiometer with the ends close together to have a 360 movement and clever firmware to calculate the output.

It seems they are 360 potentiometers indeed, as well as on the NI Kore and Akai MPD 218.

Apparently they work with two or three overlapping regions.

something like this https://www.mouser.de/ProductDetail/Alpha-Taiwan/RV112FF-40-25A-0B10K?qs=XeJtXLiO41R65P9QvUgmCw==

Damn… I want a MIDI controller with 64 of those… wonder why there still are no products like that…

Just stopping by to report that I have successfully tested 14-bit MIDI CC with MIDI-CAT building the v1-dev branch – it worked flawlessly, thank you very much @stoermelder! Also very excited that 14-bit MIDI will be part of Rack v2.

Perhaps of interest for those building their own MIDI controllers: Here is a great blog post that outlines how to use 14-bit MIDI with Teensy. The 3.2/3.5/and 3.6 versions of the board support 13-bit ADC readings and the associated code upscales to 14-bit. Apart from that, it uses the ResponsiveAnalogRead library which significantly reduces noise/jitter. My breadboard experiments with this worked out great so far.

2 Likes

That sounds very good.

So you get stable readings with more than 10 bit resolution? (I don’t believe you :smiley: please show some proof on a youtube video and tell how you did it)

The ADCs on the Teensys are actually even 16 bit… but since you can never get that stable because of the noisefloor they advertise it as “up to 13 bit” - which is probably under laboratory conditions.

If I could have 12 bit I would be completely happy, as this marks the threshold where it’s no longer possible to move a knob to an exact value. But for me, I got 10 bit at best, and it was more stable on an Arduino, which has only 10bit ADCs to begin with.

Yeah, when I was looking at it all the arduinos looked too crude. The expert sleepers Disting is accurate to 16 bits, so I used that. my (old) stuff is here: GitHub - squinkylabs/thisthing: Alternate firmware for disting

You mean it’s interesting to look at for a MIDI controller? :confused: