High resolution MIDI or OSC controllers?


    Jul 29 2017 | 3:18 pm
    The resolution problem Most of you will understand the problems of using MIDI to control parameters like amplitude and filter sweeps, where one wants a smooth response over a wide range. Standard MIDI data is limited to 7 bits, representing only 128 steps. This is not enough. You can sometimes hear the "staircase" effect as values switch.
    This fact was recognised in 1983. That's why Pitch Bend Change is a special MIDI instruction. It uses two MIDI bytes combined as 14 bits, resulting in 16,384 steps. This "high resolution" MIDI ca nbe implemented in two ways: dual CC pairs or NRPN messages.
    MIDI controllers I am compiling a list of high-resolution hardware controllers that provide rotary encoders and switches (faders optional). On the one side are expensive control surfaces (eg. Mixed Logic M24) and also DJ tools (Torq Xponent, Vestax VCI-300, Numark NS). But these are not suitable for synthesis and creative music-making, which is my focus.
    • Faderfox SC4 and Faderfox UC4
    • Behringer BCF2000 and Behringer BCR2000: implement NRPN
    • Moog Little Phatty and Moog Slim Phatty: send 14-bit CC on Filter Cutoff as well as Mod Wheel
    OSC controllers The correct answer to the limitations of MIDI is OSC. Many software programmes have adopted this standard. But again there are few hardware interfaces.
    • KMI QuNeo and KMI QuNexus
    • Monome Grid and Monome Arc
    • Madrona Labs Soundplane
    • JazzMutant Lemur (discontinued)
    • Percussa AudioCubes
    I would appreciate if anyone can adding to these lists
    (This is part of my current research. I am going to cross-post this to some other places too.)

    • Jul 29 2017 | 4:35 pm
      when using max/msp (or another environment of that kind) there might be some alternative options. for example you could use 2 7-bit controllers for "coarse" and "fine" - and do the math in your app.
      i am dreaming of a 14-bit pocket control since ever, if there is a solution without soldering let me know.
    • Jul 30 2017 | 11:32 am
      It's true there are software workarounds. One is, as you say, to have two controls, one for coarse and one for fine adjustments. We see this often with pitch controls. But this does not allow the full movement (glissando in this case) that a pitch wheel provides. The second option is to implement acceleration, so that moving the pot quicker changes values quicker. This allows one control to cover a wider range of values, but without the granularity that ensures smooth transitions. A third solution is to build one's own controller with Arduino or similar. It's easy to get 10-bit serial data to a computer, and (in my experience) 1024 values is enough. We don't necessarily need the full 14 bits. One could even package the output as a MIDI stream and provide a DIN interface. This way the home-brew unit could work with other hardware devices, independent of a computer.
    • Jul 30 2017 | 12:27 pm
      i was wondering about this, made an arduino controller with pots but it was less accurate than i thought, less than half than 1024, i don't want to flood serial all the time so it only send the sensor reading if it has changed greater than a number.
    • Jul 30 2017 | 3:36 pm
      I wish there were more options for this myself - but to add to your list, the Faderfox UC3 also supports 14-bit values for all knobs and sliders. I have both the UC3 and UC4 for this reason, and I find I prefer the longer faders on the UC3.
    • Jul 30 2017 | 6:08 pm
      Thanks, Jesse! The discontinued UC3 has 45mm faders, whereas the UC4 has 30mm, so they can fit in a row of 8 buttons. Nice to hear from someone who has used both. Ben, you make a good point about usable data range. The maximum number of values the Arduino received is only theoretically 1024. The usable range on a given pot might be smaller. I would favour using rotary encoders instead. Then the only data received is "increment" or "decrement", with no hardware-imposed limits on the values. This defers to the software (Max) how to interpret these values and constrain them to a usable range.
    • Jul 30 2017 | 6:58 pm
      I've been in a similar boat, and my solution has been to go DIY with it.
      I use a Teensy LC, which gives you 12bit resolution natively, and then an external ADC (Adafruit ADS1115) to get 14bit resolution.
      I then wrote a bunch of support code around it which handles the bit shifting, smoothing (link below), and calibration routine, storing the min/max value in the EEPROM.
      I found this guide on smoothing to be massively useful: http://damienclarke.me/code/posts/writing-a-better-noise-reducing-analogread
    • Jul 30 2017 | 6:59 pm
      Here is the Arduino code in question.
    • Jul 30 2017 | 7:28 pm
      Excellent article!
      I might well implement something with Arduino/Teensy myself, but wanted to explore off-the-shelf items too. Though the FaderFox units are not "cheap as chips", they aren't so much more than rolling my own solution, if I take into account custom fabrication of a case, etc.
    • Jul 30 2017 | 8:18 pm
      DIY is definitely a good way to go, especially if you calibrate.
      One often overlooked characteristics of MIDI controllers is the "physical resolution", which most have a ton of 'slop' at the top/bottom of the range, unless they have internal calibration routines (which better ones should).
    • Jul 30 2017 | 9:12 pm
      If the only problem of the standard 7-bit MIDI resolution is the "staircase" effect, I would simply build a "smoother" in software (temporal low-pass filter / temporal averaging). That would give you additional "steps" while moving the physical knob/fader with a very low latency, depending on the "sampling rate" of the smoothing process.
    • Jul 30 2017 | 9:19 pm
      That definitely improves things, but in certain systems, that still only offers you 127 'states' that that smoothing can fall on (unless you work out some randomizer or something, which would likely be an improvement for sub-state resolution (I'm surprised I haven't seen something like that before)).
      For example, in my case I went DIY because I'm using the controller in a feedback system, and sure, having 14-bit resolution definitely gives me better resolution/accuracy when I move (without having to rely on (very much) temporal averaging), but more importantly, I have significantly more resolution when it comes to static states the patch can land in (which in feedback, is very beneficial).
    • Jul 30 2017 | 10:36 pm
      The main problem with building a solution in software is that you have to do it repeatedly for each package you use: Max, Reaktor, Reaper with plugins, etc. Or what if you are not using a computer at all?
      The required resolution needs to be there at the input. Software workarounds are just that. One of the reason I am highlighting this issue is to raise awareness for manufacturers. Companies that make synths and controllers should be building this into their devices.
    • Jul 30 2017 | 10:39 pm
      Rodrigo wrote: One often overlooked characteristics of MIDI controllers is the "physical resolution", which most have a ton of 'slop' at the top/bottom of the range, unless they have internal calibration routines (which better ones should).
      Oh yes. All input devices should be calibrated. For Arduino, I sometimes call a routine in the setup(), so that the first ten seconds after bootup is a calibration period. Inputs do nothing in this period except look for minima and maxima. If I'm using light or distance sensors I give them a good exercise!
    • Jul 30 2017 | 11:03 pm
      I was originally going to do something like that (have a startup routine), but changed it over to receiving a specific combo of program change messages, so you can calibrate it only when needed. I also set the initial min/max to something that shouldn't give any (little) slop, while allowing the full range of adc (obviously there are tradeoffs here).
    • Jul 30 2017 | 11:44 pm
      Rodrigo wrote: That definitely improves things, but in certain systems, that still only offers you 127 'states' that that smoothing can fall on (unless you work out some randomizer or something, which would likely be an improvement for sub-state resolution (I'm surprised I haven't seen something like that before)).
      The averaging resolution and timing (sample rate) can be completely independent of the input, so you would have much more than the 128 MIDI values while operating the physical control but the "arriving destination" would always be one of the 128 steps, yes... A very useful software workaround for this kind of problem would be to have a Max patch or standalone that: a) receives single precision, regular MIDI controllers; b) smooths the result with the proposed method, creating additional detail; c) sends the result as a double precision controller through a IAC bus (MacOS) or similar architecture (Windows), in order to be used by other software, or through a physical MIDI port to other device that can make use of it.
      Anyway, this is only a workaround, the fundamental problem still remains. But, as the MIDI language predicted this necessity since the beginning of its implementation, in 1983 (control change numbers from 32 to 63 are reserved as an extension to be paired with 0 to 31) and the industry at large didn't bother, I guess it's not a priority for many people, unfortunately, hence the current state of affairs more than 30 years later...
    • Jul 31 2017 | 12:21 am
      well, one thing you can do is building a controller with 16 pitch wheels (or 16 ribbon controllers or 16 theremin controllers) which are sending on 16 different channels. IMO the best tool for frequency/pitch would be an endless-modwheel which sends pitch-wheel style data and offers an additional button which centers the value at logical 0.
      but one problem remains. most midi devices - including DAW programs or max/msp via usb interface, might not like so much data...
    • Jul 31 2017 | 12:22 am
      @Robin, I think i shall use rotary encoders next time :) I use a QuNexus for the same reason in the list.. Do you know of the Roli Seaboard? What do you think of it? ..the article about reducing noise is good, thanks
    • Jul 31 2017 | 12:34 am
      I know of the Roli products, but have little interest in a keyboard type controller, since I never really bought into the tyranny of the tetrachord! I would prefer hex-based note patterns, like the Snyderphonics Manta. The touch pads there are only 7-bit but the two assignable touch sliders are 12 bit. By the way, this is an OSC controller, so it should be added to the list above. Unfortunately it only works with Mac OS so that eliminates it from contention for me. Jeff Snyder has been working on this but other things have priority. This thread is convincing me I need to wander back into Arduino land.
    • Jul 31 2017 | 12:49 am
      If you're into the MPE thing, it'd be worthwhile looking at this thread on the lines forum: https://llllllll.co/t/mpe-touch-controller-options/5509
      Lots of cool discussion/links in there, including: http://www.synthtopia.com/content/2016/11/27/roger-linn-mpe-interview/
    • Jul 31 2017 | 1:56 am
      MPE is certainly interesting, and shows that a group of manufacturers can get together to extend MIDI. It's definitely performance-oriented and I am not a player, as such.
    • Mar 16 2018 | 10:37 pm
      Something possibly very interesting for you guys here! It's called the Ø.
      15 potentiometers, 13 bit readings upscaled to speak 14-bit MIDI. You can hook up three additional sensors with mini jacks.
    • May 05 2018 | 8:15 am
      I've just purchased the Asparion D400 controller bundle, and can confirm that this passes 12-bit values from its faders via pitch bend MIDI messages. These can be accessed using the xbendin object in max. It's a bit pricey but the D400F has motorized faders and can be extended with up to 64 physical faders by daisy chaining extension units.
      I only have a single fader pack, so 8 faders in all. But the D400T, which is the base unit, has several push encoders and a bank up/down control so I should be able to manage state in Max and use these to extend the functionality of the unit. The touch sensitive faders will respond to corresponding xbendout messages so you can automate them from within Max as well.
      The build quality is quite good and I've been able to confirm very good precision from the faders, which are reasonably quiet as well. Asparion has been very responsive over email and this seems like a good solution for high resolution work. They don't have dealers in the US but I had mine shipped from musicstore.de and it arrived pretty quickly with express shipping. Will report back as I integrate this further into my setup.
    • May 05 2018 | 11:16 am
      The Asparion looks excellent as a DAW controller. And perhaps £800 (price for fader plus transport unit) is fair enough for people doing a lot of production work.
      15 potentiometers, 13 bit readings upscaled to speak 14-bit MIDI. You can hook up three additional sensors with mini jacks.
      The Ø is built around a Teensy that is accessible for further programming. They also claim it will come with Max and Reaktor support. I must say the website is too hip for me. I'd prefer fewer moving parts and more information.
      The same applies to the open casing, which seems designed for style rather than practicality. Where I live we have dust; this device would last about a year before short-circuiting. Obviously not designed for life on the road.
      It's good to have choice, however, and €280 seems reasonable for what they are delivering.
    • May 11 2018 | 12:37 am
      Yes, the fact that the Asparion can double as a DAW controller is very nice. I also like the fact that you can expand it to a higher number of physical faders as needed, albeit via USB cables. Seems rugged but I have not tested it on the road yet.
      The Ø looks nice but I agree the casing leaves a lot to be desired.