[ardour-dev] Mackie protocol

John Anderson ardour at semiosix.com
Wed Jan 3 12:42:30 PST 2007


On Wed, 2007-01-03 at 14:50 -0500, Jesse Chappell wrote:
> On 1/3/07, John Anderson <ardour at semiosix.com> wrote:
> You don't need to match every exact sysex message with a signal in
> your protocol wrapper class, just make signals for the logical
> elements that you might use from the surface class.  If initialization
> is multi-step, then encapsulate that if appropriate....

Yeah, obviously. What I meant is that when there's a sequence of
request/response messages, it's easier to handle it using the natural
sequence of statements in one function (block, actually, for
pedanticness) and blocking io. Doing the same thing in a callback-style
environment means you require a state variable to keep track of what you
should be expecting. Or send each callback to a separate handler. Hmm,
I'm getting this going-in-circles feeling now :-p

> > * Out of curiosity mostly - where is the thread that does the reading of
> > the port? I was kinda surprised that it was emitting signals without
> > calls to Port::read().
> 
> Depends where you got the port, and on what platform you're on.  In
> your case you might have been using the port that is set as the midi
> port in ardour, in which case there is a thread running from
> session_midi.cc that services it and calls read.

I have

<MIDI-port tag="mackie" device="/dev/snd/midiC2D0" type="alsa/raw" mode="duplex"/>

and

<Option name="midi-port-name" value="mackie"/>

in my ardour.rc file. And I'm opening the port the same way that
GenericMidi does. So now I know why ardour is mysteriously reading the
port for me ;-)

> On OS X, the
> coremidi port type actually directly calls the parser because coremidi
> defines its own thread for it.  I was thinking that we may actually
> want to create a new port (or ports, considering we might have
> multiple MC units ganged together) for this surface separate from the
> control port that the generic midi control surface uses.

It would have to be ports, plural. From what I've read, if you have a
MCU and one or more extenders, each unit is on a separate midi port - no
midi-thru. And because of that there's explicitly no provision for a
device id in the protocol. For now I've relegated that issue to "deal
with it later, but bear in mind for the design".

I imagine ardour.rc would have to have something like

<MIDI-port tag="mcu" device="/dev/snd/midiC2D0" type="alsa/raw" mode="duplex"/>
<MIDI-port tag="mcu_xt_1" device="/dev/snd/midiC3D0" type="alsa/raw" mode="duplex"/>
<MIDI-port tag="mcu_xt_2" device="/dev/snd/midiC4D0" type="alsa/raw" mode="duplex"/>

.
.
.

<Protocol name="Mackie" active="yes">
	<Port master="yes" tag="mcu"/>
	<Port extender="1" tag="mcu_xt_1"/>
	<Port extender="2" tag="mcu_xt_2"/>
</Protocol>

or something like that. But more elegant.

And then someone would have to donate an MCU plus a couple of extenders,
so I can test the code properly 8-D

bye
John





More information about the Ardour-Dev mailing list