New Standard, MIDI Capability Inquiry (MIDI-CI), Paves The Way For The Future Of MIDI

At the 2018 NAMM Show, the MIDI Manufacturers Association (MMA) announced the ratification of a new extension to MIDI, MIDI Capability Inquiry.

MIDI Capability Inquiry (MIDI-CI) is designed to provide your devices and software with a standard way to ‘talk’ with each other, to find out each other’s capabilities and to configure themselves automatically for the best compatibility. It does this in three main ways: Protocol Negotiation, Profile Configuration & Property Exchange.

The new standard should allow devices and software to automatically configure themselves for maximum compatibility. For example, a MIDI controller could use MIDI-CI to ‘ask’ a synth if it supports the new MPE specification, and if so, automatically configure it. Or you could load a track in your DAW, and it could automatically configure your studio hardware the way you want it for that song.

The standard also is designed to allow for future enhancements and to provide a “fall back” mechanism. So, if a device or application does not support a new feature or a future standard, it will continue to work as defined by MIDI 1.0.

MIDI-CI paves the way for the future of MIDI, because it provides a standard way for devices and apps to ‘talk’ to each other, share information about their capabilities, and negotiate how they work together. For example, if MMA members agree to a “MIDI 2.0′ standard in the future, MIDI-CI would allow devices and apps to ask “Do you support MIDI 2.0?” and, if so, they could default to using it, rather than MIDI 1.0.

For more information on MIDI-CI, see the MMA site.

14 thoughts on “New Standard, MIDI Capability Inquiry (MIDI-CI), Paves The Way For The Future Of MIDI

    1. Carl,

      most likely the same old DIN. Two of the five pins are not used at all (a choice made to expand in the future, right back in the 80s)

  1. I know everyone is excited about MPE, for good reason, but this feels like the bigger deal to me.

    Imagine setting up a MIDI controller and having it just ‘discover’ what’s available for control from a target device. On something like the Novation SL series, you could select named control targets for each control and have all of that stuff automatically labeled. Good-bye manually entered NRPNs. I will not miss you.

    Or a MIDI track in your DAW… no need to look up what CC17 controls because the DAW can ask the target device what’s available and present those things as a named list.

    But it also allows for NEW protocols. It will use MIDI 1.0 as the lingua franca but devices could also support a new MIDI-like protocol with more CCs, high-res CCs, more channels, tunings… All negotiated over MIDI 1.0. Amazing.

    Think this overview is a little easier to consume. https://www.midi.org/articles/midi-capabilties-inquiry-presentation-at-adc

  2. Universal System Exclusive was added to handle this. It has handshaking between devices, device inquiry and response, and was designed to be expandable to cover the additional messages needed.

    Some instruments support it. Not enough though, so it’s never really caught on.

    The above proposal is a case where someone isn’t using the existing standard so they invent a new standard which is vastly more complex and which basically does the same thing the simpler one did. Now we have two standards. The situation is more confusing than before. Sure the guy who proposed the standard will add it to his instruments and tell people “I’m the guy that made that standard you never heard of.” And then the standard will just be yet another section of the standard that almost no one cares about.

    And the braying public shouts “hurrah! at last we will have the functionality”. Thirty years later, in 2048, we’ll make yet another standard as a reaction to how standard 2 never caught on. We’ll make that version yet more complex and fancy with all sorts of amazing promises. And then in 2078 we’ll have yet another go.

    1. MIDI-CI is based on Universal System Exlusive messages. The current Identity Request/Response is very limited, not comparable to CI in any way. There is no overlap between CI and existing MIDI standards.

  3. I currently have 11 MIDI devices routed through a 20 year old MIDI patchbay. I don’t use a DAW – I record to a Tascam multitrack.

    I can’t say I have any problems a new MIDI standard will address.

    Your mileage may vary, of course.

      1. IMO The clock itself is fine (I guess) but the workarounds you have to do could be so easily added to the standard, like running your sequencer at 2X tempo for a tighter clock (48ppqn) in return for losing half of the space/steps… That could be implemented with a multiplier value and you would still have your full sequencer space/steps…

        The only way to “design” a trigger pulse and the rhythm of it (for sync) is by going modular/semi-modular and analog, would just be nice to have it in one MIDI cable and for equipment that doesn’t have CV/Gate and such..

  4. MIDI 1.0 is so obsolete that it hurts, but as it looks none of the specs guys has the balls to simply say ok we’ll make a MIDI 2.0 the way it should be and if you still need MIDI 1.0 just use the converter box and that is it.
    Instead they are continuing to use all the old specs.

    1. Switch to network based protocol (latency down to micro seconds with fast/big data transfers).
    2. Stop using 7bits. Just use 32bits for everything! Loosing some bytes because of command is not using it is much better then to limit everything down to 7 or 14 bits.
    3. Make the specs that are easily expendable.

    I simply don’t understand why they are complicating so much. We are not living in 4kB world anymore. Just use the power of the network and stop supporting MIDI 1.0. Any cheap 20 usd converter box could handle the conversions from TCP/UDP to MIDI 1.0.

Leave a Reply to Aaaa Cancel reply

Your email address will not be published. Required fields are marked *