[LAD] Details about Mackie Control or Mackie Human User Interface
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
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).
More information about the Linux-audio-dev