On Mon, 20 Jul 2015, Takashi Sakamoto wrote: Done some of that. HUI is old and basically dead. I do not thiink there have been any HUI only control surfaces made for a long time. Anything that does HUI also does MCP. It is (as Paul has said) straight MIDI. The best guide I know of is the "Logic Control User's Manual" from 2002. The MIDI implementation starts on page 105. The only thing maybe a bit odd is that there are encoders that use CC increment and decrement instead of straight values, but any sw written for these surfaces is aware of it. The other thing to be aware of with MCP is that they think in banks. I would think that an AI control would be better to just have one midi control per controlable. That is, I am not sure that adding MCP to AI control makes sense. The MCP is designed for DAW control and does this well. Using it to directly control the AI where the user may have one or five surfaces (actually three seems to be the top end) means more config work, or limiting the user to one surface. Worse, there are MCP control surfaces that look like more than one MCP controller, so in that case you would be limiting the user to half of their surface. You will note the use of pitchbend for levels. CC has only 127 values which can give "zipper" artifacts. If using CC, the values need to be mapped to DB per tick and/or have SW smoothing. The top 50db of the range are most important. While not considered the best implementation, Allen & Heath in the mixers use: [(Gain+54)/64]*7F for faders with 0 being off as a special case. I am guessing that AI levels would normally be set and forget in any case, not levels that would be adjusted as a performance adjustment, though many of the AIs are fully equiped enough they can be used as live performance mixers. You get to make up your own midi map is what it finally comes down to. OSC might be a better option as the values can be floats and there is no limit to number of controls (Midi has only 127 CCs and some of those are reserved). Download and look at the X32 remote SW http://www.behringerdownload.de/X32/X32-Edit_V2.3_LINUX.tar.gz for an example. People are going to control their AI from a software application and using MIDI vs OSC does not really change the complexity too much. OSC messages are at least somewhat self documenting. OCA, or something like it, is fully discoverable and a client application can build a gui from the info it provides on the fly (including new bits being plugged in... like an ADAT box for example). Have fun :) In all seriousness, I am not one of the few people who can deal with kernel code or audio dsp code. I have been playing with jack midi... alsa midi looked too complex for someone new to coding. -- Len Ovens www.ovenwerks.net

On Tue, Jul 21, 2015 at 9:53 AM, Takashi Sakamoto <o-takashi(a)sakamocchi.jp> wrote: First of all, building support for *interpreting* incoming MIDI into a device driver is probably a bad idea on a *nix-like OS. It is just the wrong place for it. If there's a desire to have something act on incoming MCP or HUI messages, that should be a user-space demon receiving data from the driver. This means that the driver doesn't care about anything other than receiving a stream of data from the hardware and passing it on, in the same order as it was received, to any processes that are reading from the device. The device driver does not "keep state" with respect to incoming data, only the state of the hardware. Discovery in MCP and HUI is a much simpler system. In many implementations, there is no hand-shake or discovery at all: the device just powers up and can start receiving and transmitting immediately. There is no state to maintain, no keep-alive protocol. About the only thing that can sometimes be gained from the handshake is determining the type/name of the device, but this is actually rarely delivered. Lets hope it remains that way.