MIDI CI

MIDI Capability Inquiry ('CI') is part of the ongoing effort to establish a 2.0 version of the 40 years old MIDI standard. MIDI CI is meant to provide standardized protocols for devices to exchange information about their capabilities and properties. In an ideal world future MIDI hard- and software should be able to widely autoconfigure itself so that a controller for example can learn about all the available parameters on a synthesizer and can automap itself to give the user instant control.

If this sounds too good to be true, it probably is. The specifications released so far are often as strange as the whole drawn out, highly secretive process of defining them seemed to be. And if the world really needs an update to MIDI at all is another question.
There is however some gear using the defined specs coming to market from Korg and others now, so it seemed worthwhile to become familiar with it. The basic idea behind 'Property Exchange' at least goes rather well with TouchDAW.

Not MIDI 2.0, Just Sysex...

Technically none of the various specifications bundled under the CI moniker actually use the new MIDI 2.0 message format. They are all based on plain MIDI System Exclusive (Sysex) messages and will theoretically work over all the established MIDI 1.0 transports (5pin DIN, USB, RTP, Bluetooth LE etc.).

CI implementation in TouchDAW

TouchDAW implements all CI functionality in a specialized component named 'CI-Group' that can be used inside all XML defined controller layouts. In the end it is a standard layout container (ie. a 'group' or more specifically an extension of a 'tabbed group') with some additional functionality behind the scenes that automatically creates its contents. The 'CI-Group' can either fully define a custom controller if it is the only control added to a layout (as in the 'MIDI-CI' presets available on all customizable screens) or be combined with other controls in user-defined setups.

MIDI CI is NOT used with the DAW-Controller part of the app, which remains to be a hardcoded standard MCU implementation. CI will always use the app's second MIDI connection!

'CI-Groups' will create a varying number of tabs with the first (and initially only) one holding a list of CI capeable devices discovered on the MIDI connection. Once you select a device from that list, the app will exchange more Sysex with it, query for controllable parameters and build a generic controller layout that may span one or more additional tabs, depending on the number of controls the device makes available. This controller layout is then persisted in XML and will be reused the next time around given the device is present and listening again. If you select another device, tabs corresponding to device A will be removed and be replaced with what device B makes accessible.

In a nutshell CI control is a three step process with the second step usually only performed once as long as the environment does not change:
  1. (Re) Discover
  2. [ Build ]
  3. Control

Discover & Build

Before any capability information can be exchanged, devices will need to discover each other.

The 'CI Group' will automatically send out discovery messages when it is first loaded. There is also a large button labelled 'Discover' at the bottom of the first tab that can be used to trigger the process manually. When a discovery operation is in progress the button will show a spinning wheel and ignore further touches.

For every discovered device an entry will be added to the list on the first tab as shown on the left. These show the device's name, version and manufacturer information.

In most cases you will only see one device being discovered here unless you use a multi-instance capeable MIDI driver or have multiple devices hooked into one network MIDI session.
DAWs so far do not seem to pass MIDI CI sysex to synthesizer plug-ins etc.

The filled or empty squares at the bottom of the listentries indicate support for functionality defined in sub-specifications of MIDI CI:
From left to right these stand for: 'Process Inquiry', 'Property Exchange' and 'Profile Inquiry'. A filled square indicates support, an empty one means that the device does not support that specification.

To build a controller for a discovered device either double-tap an entry or select it with a single-tap and touch the button at the bottom which will be labelled 'Build' then.

Build Options

The three-dot menu button in the lower toolbar shows some options controlling how the app will build controllers for a selected device:

  • Build Profiles - If enabled and a device indicates support for some predefined control profile (see below), tabs with standard control layouts for that profile will be created.
  • Add Keyboards - When enabled every controller tab will include a one octave keyboard view sending standard MIDI Note-Ons and Offs to the controlled device to preview sounds.
  • X-ParameterList & AllCtrlList
    • Build - Controls which property listings controllers will be build from. See below for details on listing types.
    • Controls Per Row - Sets how many rotaries will be fitted into a row. Directly influences how large every single rotary will be and how many of them will fit onto a single tab.


Control...

MIDI CI defines two basic concepts of how a device can indicate its controllable parameters:

  1. Property Exchange - the most open and powerful concept. Devices will send long JSON formatted lists giving names, ranges, CC numbers etc. for each of their parameters. Controllers can then 'subscribe' to those parameters, change them and receive feedback on updated values. The specs define a standard way to transmit these lists in structs named 'AllCtrlList', which is a somewhat strange, highly verbose format ignoring most conventions established in 40 years of MIDI use. They also allow for vendor specific extensions using an 'X' prefix, though. Korg as the first manufacturer to implement MIDI CI in shipping products have introduced an alternative format named 'XParameterList', that is more practical, but still is overly verbose and highly inefficient in terms of bandwidth use etc. It has been adopted by some other vendors by now, though and it looks like things will once again come down to 'de-facto' standards set by first implementors.

  2. Profile Inquiry - a 'profile' defines a standard set of CCs that a device implementing that 'profile' must support. A device that claims to support the 'Standard CC Map Profile' for example says: 'Hey, you can send me CC number 7 to control my volume and 10 to set stereo panorama' (plus a lot of other CCs of course). The concept of profiles basically goes back to General MIDI 2.0 and does little to improve on that attempt to ensure basic interoperatability between devices. The MMA has released a number of new profiles lately, which - besides a generalized MPE specification - mostly seem to originate in some MMA chair's love for his drawbar organ and Lesley speaker cabinet.
Besides those there is a third conceptual block named 'Process Inquiry', which is supposed to deal with learning about current values of certain properties. I have so far not seen any device claiming support for those methods. Much of it is also redundant and equally handled by property subscriptions as defined in the 'Property Exchange' concepts.

MIDI CI == Lots of highly redundant data
The sheer ammount of sysex data exchanged in CI communication may result in lagging on some MIDI connections (5-pin DIN, Bluetooth).
Best use a direct USB or network connection!

Setup Example

There is not much gear around actually using CI functionality at the time being. Korg have implemented it in their standalone wavetable synthesizers Wavestate and Modwave where it is primarily used to map the synths' parameters to the 8 rotary controls on the Keystage controller keyboard. Opsix Native and the upcoming Mono/Poly should also support this. Besides those Korg products there is Woodsynth, a standalone iPad and VST / AU synthesizer from Immaculate Maple Syrup Productions. Woodsynth also implements Korg's way of doing things. All these products have free demo versions, which TouchDAW's implementation was mainly built and tested with. Below setup example refers to Wavestate Native, but should be valid for all CI devices.

MIDI CI will always require a bidirectional MIDI connection. This example will use Android's USB client mode, but any other MIDI connection will do long as data can flow in both directions.
  1. Connect your Android device to the computer running Wavestate with a USB cable, set the USB functionality to 'MIDI' and select USB / Android USB Peripheral Port on TouchDAW's second MIDI connection.

  2. Open Wavestate Native's preferences and set both MIDI in- and output to 'MIDI Function' (the computer-side port name may be different with some Android devices, Mac OS etc.).

  3. In TouchDAW go to any of the MIDI controller screens, enter Edit mode, load the 'MIDI CI' preset and exit Edit mode again.

  4. After a moment the app should show a 'Wavestate Native' entry in the device list. If that doesn't happen double-check the connection and use the 'Discover' button to try again.

  5. Double-tab the list entry. The app will then build a controller as shown above. The 40 labelled rotaries control the synth's accessible parameters and display numeric and textual feedback (The number of parameters of course depends on the synthesizer. Modwave will only ever expose four, with Woodsynth it will be even more than 40).

    The stepper / dropdown control at the top will be included if the CI device transmits a 'ProgramList' resource and can be used to switch presets.

    These generic all-rotaries controllers are built from Korg's standard 'XParameterList', which the app will prefer at its default settings. With devices not following Korg's lead or if you set the build options to include or prefer the CI-standard 'AllCtrlList' resources (which contain 'control type' hints), you will likely get faders for most controls depending on what the controlled device exposes.

  6. The constructed controller is now persisted in XML. Next time around TouchDAW will come up with the layout built from XML and will reuse it if the CI device is found again. The orange LED at the top left shows the connection state.

    If you want to change colors, add some custom extras or whatever may come to mind, you can edit the constructed controller like any other XML defined layout. However, be aware that the contents of CI-Groups are somewhat volatile and will be overwritten when another device is selected.
Touchscreen parameter control + physical keyboard

(This assumes you do not need the DAW controller part of the app)

Controllers build from MIDI CI information can be combined with a physical keyboard by making use of TouchDAW's MIDI relay option if you make the connection between TouchDAW and the CI device wirelessly (using WiFi on the app's second MIDI connection) and connect a keyboard to the Android device via USB:
  • Select the keyboard on the app's first MIDI port.

  • Go to Setup / MIDI Ports / MIDI Options and toggle the MIDI Relay switch on. Input from the Keyboard on port 1 will then be send out to port 2 merged with the controller's output and you can simultanously play the CI synth from the keyboard and modify its parameters using the touchscreen controller.