[LAD] Details about Mackie Control or Mackie Human User Interface

Len Ovens len at ovenwerks.net
Tue Jul 21 18:38:15 UTC 2015

On Tue, 21 Jul 2015, Takashi Sakamoto wrote:

>> MCP and HUI both consist of "usual MIDI messages".
>> There are a couple of sysex messages used for hand-shaking +
>> discovery; everything else is just normal CC and note messages.
> I also know the MCP and HUI is a combination of MIDI messages. What I
> concern about is the sequence. If the seeuqnce requires device drivers
> to keep state (i.e. current message has different meaning according to
> previous messages), I should have much work for it.
> In this meaning, I use the 'rule'.

The mcp surface is generally pretty "dumb". Each button sends a note on 
and note off (note on vel 0) for each press. Each LED takes the same note 
number with 127 for on 1 for flash and 0 for off. The PB are just what 
they seem and take the same info in to operate the motor sliders. The 
surface does not really keep any state information at all. The encoders 
give direction and delta not CC value. the encoder display should only be 
sent as 4 bits and the cc number is offset by 0x20 (it looks like).

There are buttons labled bankup/down but they are really just midi 
messages and expect the sw to figure out any banking scheme or not. Each 
unit needs a separate midi port... this is true even for units that have 
16 faders... they are really two units with two midi ports.

here is a link. Yes the manual is old, but the spec is still valid. I 
would judge that if this manual did not exist, the MCP surfaces would have 
gone the way of the mackie C4, which could have been a nice box... but 
open protocols are a must for adoption... even in the windows/osx world.


There are some reasons not to use MCP to control an audio card:
  - if I spend over $1k for a surface I will not be using it for the audio 
card. It will be for the DAW. Switching a surface from one application to 
another in the middle of a session is just bad.
  - There are only 8 channels, ever. Banking becomes a must. Including 
banking in an audio interface control is a pain for any coder who wants 
to make sw to control the AI (That is everyone). Many common AIs are 
18 or more channels in and out... 36 faders plus required.
  - DAWs do not include audio interface control (levels etc) anyway, 
because they are all different and the IA channel being used for any one 
DAW channel may be shared or changed during the session making a mess 
unless the AI control is a separate window... in which case a separate app 
is easier.

I think one midi CC per gain (use nrpn if you must but really 127 
divisions is enough if mapped correctly and smoothed). One note on/off 
per switchable. All assigned sequencially from 0 up (starting at 1 may 
make things easier, there is some poorly written code that does not see 
note 0... maybe that was mine :) ).

While it would seem possible to use note off as more switches, be aware 
that some SW internally saves note on vel 0 as note off events (this is 
not wrong or a bug).

Len Ovens

More information about the Linux-audio-dev mailing list