[ardour-dev] Mackie protocol

John Anderson ardour at semiosix.com
Wed Jan 3 10:25:38 PST 2007

On Sat, 2006-12-23 at 18:52 -0500, Paul Davis wrote:
> John, I'm gone and offline till January 1st.

I hope you had a good holiday.

> A brief followup to what
> Jesse wrote:
> > 
> > Pretty much, when you call read on a port, the parser is called and
> > sigc++ signals are emitted as appropriate.  The write side should be
> > pretty normal.
> all true. the idea is that the actual Port::read() is mostly irrelevant
> - the thing doing the reading just throws the data away. However, the
> Parser attached to the port will get to see all the data flowing from
> the port, and as Jesse said, emits signals according to what it sees.
> This includes a sysex message, which will deliver you the sysex message
> intact (you don't have to worry about it being fragmented across reads
> etc).
> as jesse said, i would focus on wrapping the MC sysex messages in
> sigc::signal so that the code that actually responds to a given message
> doesn't know that it was delivered via MIDI, just that "it arrived". 

It was a wee bit annoying using signals for the initialisation where
there are a couple of request/responses that need to be sent in
sequence. Anyways, it's done now. And signals are of course a good match
for all the other midi messages.

A couple of questions:

* 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().

* There are a bunch of buttons on a MCU that can be assigned to just
about anything. Some of the Logic mappings didn't really make sense for
Ardour. So I'm going with the MCU layout for now. Of course the mapping
will be easy to change if necessary.


* For the route_table - I'm assuming that it would have 8 entries - one
for each physical fader? (I'll leave the issue of the master fader til
later - mainly because my bcf doesn't have one ;-). So each time a bank
switch happens, the route_table must be repopulated according to a new
set of remote ids?

* When are the remote ids assigned to routes? Is this the responsibility
of the control surface module, or of ardour's internals?

* What's the best way to get to the pan widget/data for a route?

That's all for now.


More information about the Ardour-Dev mailing list