[ardour-dev] [ardour-users] Observations on Mackie Control Protocol using a MCU Pro

[John Anderson]

On Tue, 2007-07-03 at 21:29 -0500, Thomas Vecchione wrote:
> Ok glancing through that section of the c file now, and had a few
> questions if you have the time, its been a LONG while since I did any
> programming even semi-seriously, though I am slowly working in my
> spare time to bring it back.... 
> 
> Right now you have the sections starting at 1050(At least in the
> source from 2.0.2 that I Have currently) Transport Buttons, Session
> Signals, Transport Signals, Bank Switching, and Functions.
> 
> Now if I had to guess I would say Transport Buttons is where you are
> catching signals from the Transport Buttons on the Control Surface,

Yip.

>  and Transport Signals is where you are transmitting updates to the
> LEDs for said buttons if it changes in ardour? 

The notify_XXX methods do that. The rest are physical button handlers.
I've moved them to be in a group with the rest now.

> Session Signals is a bit confusing to me as I am not sure exactly how
> parameter changed gets used.  Is it used when the parameter is changed
> by the control surface?  Or is it called by Ardour when a parameter is
> changed internally? 

The latter.

> The rest all seem to be signals Ardour uses to update the control
> surface to internal changes correct?

Mostly. Although bank switching, for example, takes a signal from the
surface, does some work on the data structures, and then does a set of
updates to the surface.

> Transport signals seems to be a combination of update functions to be
> called by ardour, as well as functions to be called when the control
> surface is modified(Those that get a Button passed to them)?  And then
> functions seems to be a couple of custom defined functions for
> marker_press and release on the control surface? 

Yes

> I guess my question then comes down to, instead of writing individual
> functions for every possible button, why not write generic functions
> for, goto home, goto end, set marker, etc.  But then read which gets
> called by what button out of an XML file?  That would allow the
> mapping to be changed fairly easily by anyone, and would seem to fit
> with how keyboard shortcuts, for instance, are covered?

The code kindof grew up the way it did. When I wrote it I didn't see a
need to allow user control over button mapping because the Mackie spec
had clearly defined buttons. But I'm starting to see that mapping
buttons dynamically is probably a good idea.

It's also one of those tricky situations where providing for a little
bit of dynamic behaviour ends up requiring almost everything to be
dynamic. If you look at the various button handler functions you'll see
that the is enough behaviour in each handler that to expose the entire
set of buttons properly would IMHO require a scripting language rather
than an xml definition.

> As it is, the way I am reading it, a new function would be needed for
> each individual button really,

That's the role of the ruby code generation scripts. All of them are
defined in MackieButtonHandler, which MackieControlProtocol subclasses.

> and the only way to remap is in the code itself right?  

Well, in scripts/mackie-control.csv and scripts/bcf-control.csv. Which
end up as code.

> And just to confirm, mackie_surface.cc contains the actual calling of
> the individual functions for each button state correct?

Sort of. It creates data structures that simplify the mapping of methods
in MackieControlProtocol to actual midi messages, in both directions.
MackieSurface and BcfSurface are two possible mappings. See surface.h
which they both inherit from.

So in summary - button mappings are relatively easy to change or remap.
Allowing users to remap buttons is quite a bit harder. In either case
there are many unimplemented buttons, and functionality that isn't
working. For now, I'd rather see the shuttle wheel (and other MCU stuff)
working correctly than have dynamic button mapping with its tendency to
increase complexity to a point that only scripting could handle it
adequately.

bye
John