20 Jul
2015
20 Jul
'15
3:33 p.m.
Hi all,
I'm a ALSA developer. I currently focus on developing sound drivers for
devices on IEEE 1394 bus. In this developing period for Linux 4.3, I'm
working for TASCAM FireWire series such as FW-1884 and FW-1082.
Well, are there some developers who have enough knowledgement about MIDI
messaging rule for Mackie Control or Mackie Human User Interface(HUI)?
As long as investigating FW-1082 and FW-1884, these two models transfer
control messages over IEEE 1394 isochronous packets, The shape of these
messages is similar to bitmap. In detail, see my RFC on alsa-devel:
[alsa-devel] [RFC][PATCH 26/37] ALSA: firewire-tascam: add MMAP support
to show status and control message
http://mailman.alsa-project.org/pipermail/alsa-devel/2015-July/094817.html
To enable userspace applications to handle these messages, a converter
to MIDI messages is required, as Windows/OS X drivers did. In my
original plan, I off-load this task to userspace driver applications by
adding mmap(2)ed page. While, due to some reasons, it's better to
implement the converter into kernel driver.
As long as I know, for these models, there're three types of the
converter; usual MIDI messages such as Control Change (CC), Mackie
Control and Mackie Human User Interface, while I have a little
knowledgement about the latter two types.
For this occasion, I want to know the details. If a cost to implement
one of these two types, I'll use it for the converter. Else, I use usual
MIDI messages for my patchset to ALSA upstream.
Thanks
Takashi Sakamoto
20 Jul
20 Jul
3:41 p.m.
New subject: Details about Mackie Control or Mackie Human User Interface
On Mon, Jul 20, 2015 at 9:33 AM, Takashi Sakamoto
<o-takashi(a)sakamocchi.jp> wrote:
Well, are there some developers who have enough
knowledgement about MIDI
messaging rule for Mackie Control or Mackie Human User Interface(HUI)?
not sure what you mean by "rule". I'm intimately familiar with both MCP and
HUI.
As long as I know, for these models, there're
three types of the
converter; usual MIDI messages such as Control Change (CC), Mackie
Control and Mackie Human User Interface, while I have a little
knowledgement about the latter two types.
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.
21 Jul
21 Jul
3:53 p.m.
New subject: Details about Mackie Control or Mackie Human User Interface
Hi Paul and Len,
Thanks for your replies.
On Jul 20 2015 22:41, Paul Davis wrote:
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'.
Well, when DAWs and devices successfully establish the 'hand-shaking',
they must maintain the state, such as TCP? And in the 'discovery',
devices must retrieve informations from DAWs? Furthermore, in the
'rule', transactions (a set of requests/responses) are used?
On Jul 21 2015 01:25, Len Ovens wrote:
On Mon, Jul 20, 2015 at 9:33 AM, Takashi Sakamoto
<o-takashi(a)sakamocchi.jp> wrote:
Great.
Well, are there some developers who have enough
knowledgement about MIDI
messaging rule for Mackie Control or Mackie Human User Interface(HUI)?
not sure what you mean by "rule". I'm intimately familiar with both MCP and
HUI. As long as I
know, for these models, there're three types of the
converter; usual MIDI messages such as Control Change (CC), Mackie
Control and Mackie Human User Interface, while I have a little
knowledgement about the latter two types.
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. 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.
It's noce, thanks. But the metering is one of my headaches...
On Jul 21 2015 01:25, Len Ovens wrote:
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.
I think you mean that rough approximation fomula in acoustics
engineering for human perception (i.e. ISO 226:2003).
On 2015年07月21日 01:25, Len Ovens wrote:
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).
Currently, ALSA middleware has no framework for Open Sound Control. It
just has implementations for MIDI like messages. In this time, I use
rawmidi interface for my purpose. The MIDI messages will be available
for userspace applications to read from ALSA sequencer functionality.
Thanks
Takashi Sakamoto
5:06 p.m.
New subject: Details about Mackie Control or Mackie Human User Interface
On Tue, Jul 21, 2015 at 9:53 AM, Takashi Sakamoto
<o-takashi(a)sakamocchi.jp> wrote:
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'.
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.
Well, when DAWs and devices successfully establish the 'hand-shaking',
they must maintain the state, such as TCP?
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.
Currently, ALSA middleware has no framework for Open
Sound Control.
Lets hope it remains that way.
8:39 p.m.
On Tue, 21 Jul 2015, Takashi Sakamoto wrote:
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.
http://stash.reaper.fm/2063/LogicControl_EN.pdf
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
www.ovenwerks.net
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'.
20 Jul
20 Jul
6:26 p.m.
On Mon, 20 Jul 2015, Takashi Sakamoto wrote:
Well, are there some developers who have enough
knowledgement about MIDI
messaging rule for Mackie Control or Mackie Human User Interface(HUI)?
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
3442
days inactive
3443
days old
linux-audio-dev@lists.linuxaudio.org
5 comments
3 participants
participants (3)
-
Len Ovens -
Paul Davis -
Takashi Sakamoto