High-Resolution MIDI Controller

For an older standard, MIDI has remarkable staying power in the music industry. It remains the de facto digital interface between computers and instruments thanks to its open nature, but its age does show a little bit. Sending control change (CC) messages, for example, was originally designed to fit within seven bits, which doesn’t give particularly fine resolution compared to more capable modern computers. To work around that, a fourteen-bit message is possible, doubling the resolution, and this MIDI interface uses this larger amount of data to send these high-resolution CC messages.

The 14-bit messages are actually fairly well documented but are a bit obscure, with very limited hardware support. To that end, [Gero] set about building this control interface to solve that problem. It’s made up of only eight knobs, each of which is mapped one-to-one to a parameter on the computer, allowing the interface to feel more like an analog device where the knob corresponds directly to a change in an aspect of the sound. The platform is built around a Teensy 4.0 and some multiplexers to handle all of the knobs, with the open source software available for anyone to use to modify their actions. [Gero] was aiming for high fidelity for all aspects of this controller, not just the improved digital resolution, and made a number of other improvements to it as well like re-greasing the potentiometer knobs and a custom 3D printed enclosure.

All of the software is available for use, as well as the files to print the case. [Gero] is also working on a PCB to make the construction of the device a little more streamlined, but for now, it requires a bit of soldering off-the-shelf parts together. The MIDI standard is open as well, which allows for a lot of innovation in the creation of musical instruments from unique hardware. This project builds a MIDI synthesizer with parts from a Sega Genesis.

20 thoughts on “High-Resolution MIDI Controller

      1. It depends on how you count “resolution”. There’s also other factors such as the effective number of bits of your AD converter (ENOB), which takes into account the noise floor of your circuit.

        Even if you encode something at 14 bits, your effective noise floor and/or offsets can actually account for just 6-7 bits anyways, so you don’t gain anything.

        1. There is no noise in MIDI; these digital control changes are used for synthesis parameters. These digital numbers arrive always 100% from device to device, unless you have cables longer than 6 meter / 20 feet (which are not even sold so that is pretty impossible).

        2. Unless the potentiometers and circuit are super high quality/tolerance, this is the correct answer. MIDI is digital but the value sent down needs to be read from an analog potentiometer which is affected by noise and component tolerance.

  1. Good idea, and one I’ve pondered pursuing… but I can imagine a flood of midi data from EM noise, alone. I didn’t see any mention about this…
    I think that’s /why/ most controller knobs are encoders, as well as why they use acceleration. Imagine a tiny jiggle to a high-res encoder knob from a table vibrating from a subwoofer… 8 Continuous controller commands at 120Hz would flood the midi bandwidth. So, the “goopy” feeling of most controller knobs is a result of software on the encoder-side that only responds to a multitude of encoder-ticks in a single direction.
    But, analog potentiometers would have similar problems; aside from physical vibration, electrical noise (60Hz) could easily cause a single bit change in a 14bit 3.3V range!
    I gather that this isn’t so much a problem with [Gero’s] setup because it’s not being merged into a midi data stream that goes to devices, but is instead its own dedicated midi port, sending *only* these commands (no timing-sensitive stuff like notes), to a computer, which these days can easily handle several midi ports’ worth of input bandwidth simultaneously… but… what when trying to output it all to e.g. an external device?

    1. You work some hysteresis functions into your code, or just choose a ‘larger than you need’ ADC, so in this case, use a 16bit ADC and you can lose the lowest 2 bits where all the noise is.

      1. The choice of ADC doesn’t eliminate the analog noise present in the circuit. It merely measures it more accurately. You have to do software filtering and quantization anyways to arrive at some “definite” value.

        There’s two schools of thought for this as far as I can recon. One is to pass any errors along and assume that the further processing stages average it out, or to filter the input by strict criteria and only pass definite discrete output values. If you’re doing analog synths, the first approach is suitable because the errors do average out. If you’re doing digital synths then you can get weird glitches.

    2. The vibration issue is one reason why many controllers and instruments use relatively stiff encoders and potentiometers (another is that people conflate stiffness with quality, but it’s just a parameter when ordering from the factory, who will fill the component with different types of goop). You’ll definitely want some kind of filtering on your inputs in any case, especially considering that encoders become noisier with age.

      The bandwidth isn’t that much of an issue in my experience, a human can’t twiddle that many knobs at one time.

    3. Hi, author here! You’re right of course, but I’ve taken some measures against unwanted CC messages and I’ve tested it pretty thoroughly. First of all, the actual resolution is 12bit which still feels a bit excessive, I might go back to 10bit. Then I added a deadzone handling where you have to move the pot a bit before it starts picking up the changes, and after a period of very little changes, it goes back into deadzone mode.
      Pickup feels instant, the only issue is very slow movements, which is why I added the idea with a shift button for smaller increments to the docs.
      For testing it, I let it run for a couple of hours while receiving MIDI data to update the LEDs and I did things like knock the table or moving the case without touching the knobs.

      1. When I was doing something similar a number of years ago with a linear potentiometer to generate note and pitch-bend data, I, building on some other similar projects, avoided the dead zone with some digital software filtering, using this little library http://www.earlevel.com/main/2012/11/26/biquad-c-source-code/. That got rid of the high frequency noise/jitter and allowed me to also prioritize faster changes without cutting out low, slow movements entirely.

    4. He does say he’s only doing 12-bit resolution, not 14. But in practice, having done analog MIDI-based control interfaces before using potentiometers, you do a bunch of filtering to handle noise in the signal and you can definitely get useful high-resolution data (limited primarily by the quality of your potentiometers and how much work you want to do). Ideally you have an analog low-pass filter on each input to eliminate aliasing from high frequency noise, but I did fine with all software filtering. I was using this to generate note and pitch-bend data in combination to make a continuous pitch ribbon controller with pressure sensitivity using a force sensitive resistor and a long linear soft potentiometer. Worked great once I got the parameters tuned correctly to filter out noise and linearize the reponse (so that the difference between two pitches was the same anywhere on the ribbon and the pressure sensitivity had enough resolution without being too twitchy).

  2. Hi res seems redundant. Imagine you have to switch something from 0 to max – how many spins of the knob will you have to do?
    A more reasonable improvement seems to make knobs with a changeable value.
    On the graph from 0 to 127 (midi), a knob can switch +1, +3 , +10 values at a time. This way if a precision control is needed – use +1 mode, if you want to switch it fast – use +10

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.