14 bit midi in 1.0?

VCV Rack
43

I’m super interested in 14-bit ccs.

I wanted to also note that it would be great to be able to output 14-bit ccs in MSB/LSB pairs. Seems like that might be easier to implement? Expert Sleepers FH-2 midi to cv converter uses 14-bit MSB/LSB pairs. So we could get 14-bit resolution CV out of that if there were a way to send it from VCV. Here’s how Expert Sleepers describes the way it works in the FH-2 manual:

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.

44

Also worth noting that pitchbend messages are 14-bit. So if you’re making a custom controller, and are OK with 16 controls or less, one possible way to go is to just use the pitchbend messages on each channel.

45

Dr. Lippold Haken has given a nice solution for this 14bit CCs issue:

he calls the solution to be an addendum for the MPE standard which he calls MPE+ It waits for the LSB, but if it doesn’t come in the next message it just uses the MSB coarser value.

2 Likes
46

this is a solution, but it could get confusing if someone expects to use a 14bit control and doesn’t know the LSB CC is already taken… there would need to be some kind of an alert for that, for the person to remap the CC. I believe it is more elegant to disable mapping the LSB CCs from the MIDI standard: https://www.midi.org/specifications-old/item/table-3-control-change-messages-data-bytes-2

47

Glad to see someone acknowledge that there are issues with14 bit midi.

1 Like
48

Just an update: I was poked by Peter Kirn to look at this again. Basically we need a list of hardware that implements 14-bit values in any way through MIDI. I’m not interested in implementing some theoretical standard if no consumer devices support it. So if anyone owns or has heard of hardware supporting values with more than 7 bits, list them here.

49

I own a Behringer BCF2000 & Novation ZeroSLMK2 which both support absolute 14bits midi CC.

Also this one supports it : http://www.faderfox.de/ec4.html

And I think the widely used BCR2000 has 14bits CC too

50

Lots of problems I’d need to resolve.

  • I’ve seen 4 methods so far for sending 14-bit MIDI in the wild. Which controllers can use which methods?

    • MSB/LSB: CC #n for MSB and #n+32 for LSB
    • NRPC
    • MPE pitch wheel: channels 0-15
    • DX7 parameter change SysEx

  • Is there a standard order of MSB and LSB messages? Does MSB (CC 0-31) come first, or LSB (CC 32-63), or is it undefined?

  • There’s also this:

Basically, 14-bit MIDI is a mess. The next person that asks me “Can you implement 14-bit MIDI?” I’ll tell them their request is not specific enough.

1 Like
51

As I mentioned (boasted?) a while ago, I used to bring this up at the yearly Midi Manufactures Association meetings in the 80’s. Never got any traction. People didn’t seem to understand there was a serious ambiguity in the spec.

1 Like
52

Teensy microcontrollers support whichever MIDI bit pattern you want. I am currently translating 16-bit numbers into 3 CC messages and it works flawlessly (with Max as receiver). I use Teensy on at least 3 devices appearing as MIDI controllers on my computer, all with high-resolution CC messages. With 14-bit messages, I stick to the rule of having the MSB on low controller numbers and the LSB on high numbers.

By the way, Max can send high-res messages as well (in whichever flavour you want). But it’s not hardware, still it can be interesting to couple it to Rack.

Behringer BCF2000 has already been cited, indeed it’s a nice controller for high-resolution MIDI (even if it sends only 10 bits instead of 14 actually, a limitation linked to the ADCs probably).

I understand that the actual implementation of high-res MIDI messages on commercial devices is not standard but for pitch bend at least the MIDI standard is quite clear about the way it’s supposed to be implemented so just having Rack able to understand that one would be nice.

1 Like
53
1 Like
54

How does it work? When the core module receives an LSB it immediately combines that LSB with whatever the previous MSB was? Or does it wait to receive a pair of them? Lacking a standard, I’ve never understood how to interpret, for example: [00 , 7f] -> [1, 00]. So we start at combined x7f. Then when we get the MSB 1, to we immediately combine them to get xff? And then when we get the new LSB go back down to x80? That would make us jump an entire MSB before we could see a tinny LSB change.

55

When in 14-bit MSB/LSB mode, MIDI-CC waits for an LSB message before setting the final value.

56

Is there a standard such that sender always sends a pair in that order?

57

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).

58

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.

59

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.

60

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.

61

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.

62

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