|
||||
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:
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:
|
||||
Control... MIDI CI defines two basic concepts of how a device can indicate its controllable parameters:
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 ![]() 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.
|
||||
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:
|
||||
|