Agree–but, in practice, I’ve had no trouble actually using them to make music once they’re set up correctly. I think it’s a case of “worse in theory.” Have you (or anyone else this far down this thread) had issues with their use in contemporary setups?
I suspect the problem are was just avoided for the most part. Perhaps the more interesting question is was there a good rationale for not doing it right to start with? Bruce might have some insight. I’ve been avoiding the whole thing by sending the controller over normal USB serial (not MIDI), and using the tendency of a lot of these instruments (Linux lv2, fsthost vst wrapper, customized VCV) to provide a way of mashing in a float instead of a seven bit int. I.e. I avoid MIDI altogether for high res control.
Excellent write up! I wish this was under its own thread (for posterity).
I do think maybe you are being a little generous to the old MMA. We were not a deliberative body of serious people at all. Chris Meyer (of patch and tweak fame) and I have recently apologized to each other for our…. uh “youthful enthusiasm”? I think it would be fair to say there were all kinds of people in the MMA, some intelligent and thoughtful, some arrogant and annoying (me!), some only cared about their very esoteric areas of music, etc…
In any case, there was never any serious discussion about 14 bit controllers. Synths didn’t send them, so it was pretty theoretical. It should have been obvious that terrible glitches would occur, but I think people either didn’t understand the issue or just didn’t care. So what’s in the spec probably came directly from what someone at Sequential or Roland wrote down in haste. I could have tried harder to make people care, but I didn’t.
1 Like
I think also, we were pretty much in the land of 8 bit MCUs and slow serial. (Nice things like the 68000 and z8000 were for workstations and minicomputers.) That it was also pretty seat-of-the-pants isn’t that surprising. I think the key thing is that it (like a lot of computer tech) didn’t marinate enough before being launched to the public and standardized. One doesn’t have to look too hard to find this pattern repeated often in computer tech. (Just how many bodges live in the current web, IoT, or the smartphone world?)
1 Like
That’s all true. But even back then we used “double precision” to do 16 bit arithmetic. Otherwise the VCO pitches would be too far out of tune. And of course pitch bend was always “special” in being unambiguously 14 bits. btw, we used a 2 Mhz 6502, so it was like having two whole Apple-II in there. Or two terminators.
1 Like
Didn’t the first Fairlight model use a pair of eight bit CPUs too?
Nasty thing about bend is that all my controllers might as well send a 7 bit MIDI given their poor resolution. The mod wheel (or stick axis) is about the same. I don’t know if it’s just poor ADC or not wanting to swamp the 31.25KBaud line.
I don’t know what was in the Fairlight, but I believe you. And pitch bend you don’t save any serial bytes by sending only 7 do you? My memory is that is always a 3 byte message. Or two with running status?
You’re right that the individual messages are the same length, but you’re sending fewer for a given lever/wheel displacement. I.e. I’m seeing maybe 48 (and sometimes fewer) for the PB to one side or the mod wheel. If you don’t slew, you get yucky bends, and with say a two octave bend, it sounds pretty crap even then. The units in question are Roland APro series and Korg Kontrol49s.
Oh, ok. But I doubt anyone did that as an intentional optimization. I think low quality A/D and bad analog circuitry and bad PCB layout made 7 bits. My synth (Voyetra-8) suffered from those issues. We didn’t even send pitchbend (long story), but for sure I had a difficult time getting even 7 bits from the front panel pots.
I’d call poor bend res a pessimization. Funny that with off-the-shelf MCUs these days, you can get all you need as far at the A/D. BTDT.
Agree that pots are nasty noisy things. I have a fairly slow moving average filtering with my Arduino prototypes, the reading would be stupidly jumpy otherwise. No idea if conductive plastic pots are better in this regard. I’ve just used junk out of my salvage box.
I happen to have found this discussion just at the right moment in time. I was just sitting down to start a new module, for my experiments with making a midi controller with greater bit depth. I have read the spec as mentioned above r.e handling the MSB and LSB independently and have been wondering how this works in practice. I am correct in thinking there is no 14 bit midi-cc module in the library?
I am yet to convince myself having a greater bit depth will have a significant positive impact, as the timing resolution I expect will also have an impact of how well the improved accuracy is perceived. With all this extra data from the improved resolution, I am interested to see how this performs.
From what I’ve seen >8bits resolution in MCU A/D is available, but not the norm. When I looked at this 5 years ago that’s why we did firmware for ES Disting, rather than Adruino.
Should look at the code for the core modules. I have to confess I have not. I remember the 14 bit thing coming up in discussions with Andrew, but I don’t remember the context. don’t know if it was for old MIDI or just MPE (is that the right acronym?)
With a 382P based nano clone I’m getting a pretty stable most significant nine bits off my Hall sticks and with filtering, a pretty clean 10 bits off both Hall and regular carbon pots. There are some +/- lsb jumps, but they are fairly infrequent. I don’t have any of the MCUs sporting 12bit ADC, so I have no idea how dirty the Halls are in that. I expect the pots would lose badly though.
Pi pico’s have an advertised 12 bit resolution and cost £3.60 here. My initial experiments showed the noise floor at 5 bits, after some reading around I managed to increase this to 9 bits, by adding a shunt diode to the reference voltage, and switching power supply modes. I feel to get any more bit depth I may look at replacing the pots.
Good call on looking at the core module code
This is ugly, but it kills noise fairly well. The assumption is that the noise is centered around a value determined by the pot shaft position. I don’t know the distribution, but it seems to do what I want. The type punning is used to provide a weighted average without using floats. This is for only one pot, but the macros make it fairly easy to use several.
You’ll need to hack this up for Pi Picos as that’s a different word and ADC size.
Ugh! There’s a bug in that code. The last line in setup should read INIT_POT(potval, A0);
I actually fixed that typo during testing, but it must have not gotten copied back to the repo.
Thanks for the code. I have done some experimenting with filtering and can see improvements on bit depth, but at the cost of time resolution. I am now keen to try this out in vcv to see how much of an impact filtering has.
That average takes a fairly large number of samples to converge, but it’s free running, and on the nano seems to track knobs and sticks well. For knobs I’m really looking at Hall rotational position encoders. There, you can read 'em out with I2C, and the digitization comes for free. Sadly, the one I have greatest interest (as5601) in seems out of stock EVERYWHERE despite having “production” status by the manufacturer. Key benefit is that is has high enough resolution, and it can always correspond to whatever soft synth it is controlling at the moment. That one in particular can detect change in the gap-to-magnet, so you can have a push button feature.
Even though they are somewhat spendier, you might also look at the SAMD21 based cards. You get more ADCs, and there’s facility for capacitive sense if you want that.
Lots of interesting stuff happening here, will catch up w/the rest of it later, but there’s @stoermelder’s implementation in MIDI-CAT; haven’t read the code yet but at a glance it looks like it needs to see both the MSB and LSB before it updates. Dev version only, so, not technically in the library, @curlymorphic, but library-adjacent. Here’s a pickup point:
14-bit input in V2 was confirmed in the devlog on Feb '20.
14-bit output is a Rack V2 milestone having been accepted as a FR.
Here’s an earlier thread with @Schabbes and others making the same points as above about waiting. (Sounds like @Vortico is using the MSB/wait for LSB approach).
Mod(s), if you roll by and feel so inclined, this could probably get split ∓ post #14 into its own thread so that it’s easier to find for anyone interested in 14-bit MIDI. (The irony being that the nOb is not a MIDI controller 
)