MIDI Binding Maps for Ardour 3.0 and later versions

Ardour 2.X supported MIDI learning for more or less any control. This was a nice feature that quite a few other DAWs have now provided, but it didn't allow Ardour to work "out of the box" with sensible defaults for existing commercial MIDI controllers. In Ardour 3 and later versions, we have augmented the MIDI learn feature with the ability to load a MIDI binding map for a given controller, which can set up an arbitrary number of physical controls with anything inside Ardour that can be controlled. At this time, these binding maps need to be created with a text editor, but we currently have presets for

  • Behringer BCF 2000
  • Korg_nanoKONTROL
  • M-Audio Oxygen 8 v2
  • Roland SI-24
  • Behringer DDX3216
  • M-Audio Axiom 25

MIDI binding maps are accessible by double clicking on the "Generic MIDI" line in the Control Surfaces tab of the Ardour preferences dialog. Ardour will retain your chosen map after you choose one.

The information below describes in great detail how to create a new MIDI binding map.

The Basic Concept

Since the beginning of time (well, sometime early in the 2.X series), Ardour has had the concept of identifying each track and bus with a remote control ID. This ID uniquely identifies a track or bus so that when messages arrive from elsewhere (MIDI or OSC), we can determine which track or bus they are intended to control. Ardour has a number of ways of assigning remote control IDs, but they don't really matter very much when creating MIDI binding maps, so we won't discuss that here. You just need to know that there is a "first track" and its remote control ID is 1, and so on.

Getting Started

MIDI bindings are stored in files with the suffix ".map" attached to their name. The minimal content looks like this:

<?xml version="1.0" encoding="UTF-8"?>
<ArdourMIDIBindings version="1.0.0" name="The name of this set of bindings">
So, to start, create a file with that as the initial contents.

Finding out what your MIDI control surface sends

This is the most complex part of the job, but its still not very hard. You need to connect the control surface to an application that will show you the information that the device sends each time you modify a knob, slider, button etc. There are a variety of such applications (notably gmidimon and kmidimon, but you can actually use Ardour for this if you want. Start Ardour in a terminal window, connect MIDI ports up, and in the Preferences window, enable "Trace Input" on the relevant MIDI port. A full trace of the MIDI data received will show up in the terminal window. (Note: in Ardour3, you get a dedicated, custom dialog for this kind of tracing)

Types of Bindings

There are two basic kinds of bindings you can make between a MIDI message and something inside Ardour. The first is a binding to a specific parameter of a track or bus. The second is a binding to a function that will change Ardour's state in some way.

Binding to Track/Bus controls

A track/bus binding has one of two basic structures

  <Binding msg specification  uri="... control address ..."/>
  <Binding msg specification  function="... function name ..."/>

Message specifications

You can create a binding for either 3 types of channel messages, or for a system exclusive ("sysex") message. A channel message specification looks like this:

   <Binding channel="1" ctl="13" ....
This defines a binding for a MIDI Continuous Controller message involving controller 13, arriving on channel 1. There are 16 MIDI channels, numbered 1 to 16. Where the example above says ctl, you can alternatively use note (to create binding for a Note On message) or pgm (to create a binding for a Program Change message).

You can also bind sysex messages:

  <Binding sysex="f0 0 0 e 9 0 5b f7" ....
  <Binding sysex="f0 7f 0 6 7 f7" ....
The string after the sysex= part is the sequence of MIDI bytes, as hexadecimal values, that make up the sysex message.

Finally, you can bind a totally arbitrary MIDI message:

  <Binding msg="f0 0 0 e 9 0 5b f7" ....
  <Binding msg="80 60 40" ....
The string after the msg= part is the sequence of MIDI bytes, as hexadecimal values, that make up the message you want to bind. Using this is slightly less efficient than the other variants shown above, but is useful for some oddly designed control devices.

Control address

A control address defines what the binding will actually control. There are quite a few different things that can be specified here:

Each of the specifications needs an address, which takes various forms too. For track-level controls (solo/gain/mute/recenable), the address is one the following:
a number, eg. "1"
identifies a track or bus by its remote control ID
B, followed by a number
identifies a track or bus by its remote control ID within the current bank (see below for more on banks)
one or more words
identifies a track or bus by its name
For send/insert/plugin controls, the address consists of a track/bus address (as just described) followed by a number identifying the plugin/send (starting from 1). For plugin parameters, there is an additional third component: a number identifying the plugin parameter number (starting from 1).

One additional feature: for solo and mute bindings, you can also add momentary="yes" after the control address. This is useful primarily for NoteOn bindings - when Ardour gets the NoteOn it will solo or mute the targetted track or bus, but then when a NoteOff arrives, it will un-solo or un-mute it.

Bindings to Ardour "functions"

Rather than binding to a specific track/bus control, it may be useful to have a MIDI controller able to alter some part of Ardour's state. A binding definition that does this looks like this:

  <Binding channel="1" note="13" function="transport-roll"/>
In this case, a NoteOn message for note number 13 (on channel 1) will start the transport rolling. The following function names are available:

stop the transport
start the transport "rolling"
move the playhead to the zero position
move the playhead to the start marker
move the playhead to the end marker
turn on loop playback
enable the global record button
disable the global record button
Move track/bus mapping to the next bank (see Banks below)
Move track/bus mapping to the previous bank (see Banks below)

Binding to Ardour "actions"

You can also bind a sysex or arbitrary message to any of the items that occur in Ardour's main menu (and its submenus). The best place to look for the (long) list of how to address each item is in your keybindings file, which will contain lines that look like this:

(gtk_accel_path "<Actions>/Editor/temporal-zoom-in" "equal")
To create a binding between an arbitrary MIDI message (we'll use a note-off on channel 1 of MIDI note 60 (hex) with release velocity 40 (hex)), the binding file would contain:
   <Binding msg="80 60 40" action="Editor/temporal-zoom-in"/>
The general rule, when taken an item from the keybindings file and using it in a MIDI binding is to simply strip the <Action> prefix of the second field in the keybinding definition.

Banks and Banking

Because many modern control surfaces offer per-track/bus controls for far fewer tracks & busses than many users want to control, Ardour offers the relatively common place concept of "banks". Banks to allow you to relatively easily control any number of tracks and/or busses regardless of how many faders/knobs etc. your control surface has. To use banking, the control addresses must be specified using the bank relative format mentioned above ("B1" to identify the first track of a bank of tracks, rather than "1" to identify the first track).

One very important extra piece of information is required to use banking: an extra line near the start of the list of bindings that specifies how many tracks/busses to use per bank. If the device has 8 faders, then 8 would be a sensible value to use for this. The line looks like this:

   <DeviceInfo bank-size="8"/>
In addition, you probably want to ensure that you bind something on the control surface to the next-bank and prev-bank functions, otherwise you and other users will have to use the mouse and the GUI to change banks, which rather defeats the purpose of the bindings.

A Complete (though muddled) Example

<?xml version="1.0" encoding="UTF-8"?>
<ArdourMIDIBindings version="1.0.0" name="pc1600x transport controls">
  <DeviceInfo bank-size="16"/>
  <Binding channel="1" ctl="1"   uri="/route/gain B1"/>
  <Binding channel="1" ctl="2"   uri="/route/gain B2"/>
  <Binding channel="1" ctl="3"   uri="/route/send/gain B1 1"/>
  <Binding channel="1" ctl="4"   uri="/route/plugin/parameter B1 1 1"/>
  <Binding channel="1" ctl="6"   uri="/bus/gain master"/>

  <Binding channel="1" note="1"  uri="/route/solo B1"/>
  <Binding channel="1" note="2"  uri="/route/solo B2" momentary="yes"/>

  <Binding channel="1" note="15"  uri="/route/mute B1" momentary="yes"/>
  <Binding channel="1" note="16"  uri="/route/mute B2" momentary="yes"/>

  <Binding sysex="f0 0 0 e 9 0 5b f7" function="transport-start"/>
  <Binding sysex="f0 7f 0 6 7 f7" function="rec-disable"/>
  <Binding sysex="f0 7f 0 6 6 f7" function="rec-enable"/>
  <Binding sysex="f0 0 0 e 9 0 53 0 0 f7" function="loop-toggle"/>

  <Binding channel="1" note="13" function="transport-roll"/>
  <Binding channel="1" note="14" function="transport-stop"/>
  <Binding channel="1" note="12" function="transport-start"/>
  <Binding channel="1" note="11" function="transport-zero"/>
  <Binding channel="1" note="10" function="transport-end"/>

Please note that channel, controller and note numbers are specified as decimal numbers in the ranges 1-16, 0-127 and 0-127 respectively (the channel range may change at some point)

I think gmidimon site is

I think gmidimon site is down.


Will use Ardour to figure out for M-Audio Oxygen8 V2....

Wow, this is amazing. This is

Wow, this is amazing. This is exactly the kind of feature / information I'm looking for. I'll make my own bindings file today :)

One small issue though: would it be possible to expose the functionality of "move play-head to edit point"? I find that button extremely useful when recording punches, and would love to be able to bind that to midi button. I guess on a more general note, are there more functions than ones listed above. In an ideal world, a user would be able to bind any non-toggle midi button to any functionality currently provided by a key on the keyboard. Just an idea, I don't want to seem ungrateful. I'm thrilled that you guys are working on midi surface stuff at all.

Thanks for this! I'll be posting a my bindings soon.

-- Alex the Feature Creep

I think that's a good idea.

I think that's a good idea. I'm going to try my hand with my BCF2000 later today.

Ok, I hope I got it

Ok, I hope I got it right.

M-Audio Oxygen8 V2

This is a really simple and basic device it only has 8 physical dials (Virtually 128 with the channels). But mostly all I'm providing here is just the transport button functions (Stop, Play, Loop, etc).


Let me know if you need something else.

Thanks for making such a nice MIDI DBase!

@joegiampoli: that looks

@joegiampoli: that looks good, but lets get the dials in as well, controlling volume on banked tracks, perhaps.

hi there, i would like to

hi there,

i would like to help too with an m-audio axiom 25.
i have a stupid question, but is the binding working ?
i am trying to get the transport buttons working, with no success.
how can i "activate" the bindings ?
i am using A3 to find out what the MIDI control surface sends.

just to let people know, they

just to let people know,
they can also use qtractor to get the midi commands, if like me they don't have kmidimin or gmidimin.
the commands are displayed in the messages windows

@ Dazgard: In my case with

@ Dazgard:

In my case with M-Audio Oxygen8V2, I had to program it with the values provided in the manual and save it to a preset in the Oxygen. Then I connect it via qjackctl to 0:control in ardour , then in ardour go to options>control surfaces>generic midi

Then you should be able to monitor the bindings in the terminal window the way Paul explained.

@ joegiampaoli i can monitor

@ joegiampaoli
i can monitor the commands in ardour 3 terminal window the way Paul explained. i can see sysex messages when using the transport buttons on my axiom25 and i can see controller messages. here's an output from the MIDI trace control window :

22:45:00.283565 Sysex (6) = [f0 7f 7f 06 03 f7]
22:45:04.352509 Controller chn 1 62 21
22:45:04.352551 Controller chn 1 63 01
22:45:04.352562 Controller chn 1 06 0c
22:45:04.395126 Controller chn 1 06 0a
22:45:04.437817 Controller chn 1 62 21
22:45:04.437854 Controller chn 1 63 01
22:45:04.437865 Controller chn 1 06 00

The sysex is from a transport button
The controller ones from a dial button

bye the way, my axiom is configured to send MMC messages when using the transport buttons and those are working just fine. maybe i should change the axiom preset to something else. just the way i did to have MMC working

@ Dazgard: My wrong, I made a

@ Dazgard:

My wrong, I made a mistake about saying to create a patch in your Axiom and then go to Ardour to see the MIDI messages.

If you do that you'll get a "System Exclusive" message in terminal from Ardour, which means that the specific control is already taken or programmed in better words. What we want to do is start with a completely blank patch in our device, (that means no personal preferences), that way, when a person hooks their MIDI device directly to Ardour they don't have to re-program it the way we have it, if we provide the info from a blank patch it will act as a plug n' play with default settings making better compatibility between the device and the settings in Ardour Database.

So don't program or assign anything. Just hook up with a clean or reseted patch from the device and monitor what the controls say in the terminal.

So the info you provided (if it is without assigning anything) should do. Just build your xml file with those values, because from them I can't tell what each one belongs to what control.

@ Paul: Ok, I will add the 8

@ Paul:

Ok, I will add the 8 dials also but just a few questions:

1.- Do I create for all 128 "virtual" dials (16 ch), Or do you only need the first channel? Because looking at output in console, the number for controller doesn't change....

2.- When I turn a dial I get a message like this:

control input: Channel 1 Controller 91 Value 31

with value being the variable from 0 to 127, how do I treat that? or not needed?

3.- So if a dial will control a track level, with the code in question 2, how would I assing to control a track level?


@joegiampoli: not sure what

@joegiampoli: not sure what to do about programming all of them ... do at least 2 channels' worth. To bind to route gain:

<Binding channel="1" ctl="91" uri="/route/gain B1"/>

What about pan control for

What about pan control for each (possibly banked) channel?

I've created a map file for one of the BCF2000 factory presets (number 2), but using a (possibly incorrect) assumed routing for pan control.

I don't have Ardour-3 installed, though, so I can't test to see if what I've done works. It should, though (except for perhaps the pan config I've done).

Any chance someone could comment on whether panning is controllable via the mapping described on this page? If so, I can adjust what I've done to suit, and contribute it as a BCF2000 mapping.

Ok, updated my

Ok, updated my xml.


Did it for 4 channels, total of 32 dials, ctl numbers do not change, only channel value. The only way the ctl value changes is when changing a preset on the device. So in other words should work if the user is using the factory default 01 preset of the device.

I forgot to place the rec-disable function. So I assigned it to the same one for rec-enable button, not sure if that can be done, if not then take out the rec-disable line for that same one (ctl 25).

About panning like therockgarden says, can panning be assigned? If so how? and if possible I'll be glad to update my file to do that in such a way that the 4 bottom controls will adjust levels ant the top 4 will pan, and then add an extra 4 channels. But then, I guess it would only be possible for mono tracks only.....otherwise, how to control 2 pans with one control?

I start working on M-Audio

I start working on M-Audio Keystation Pro-88, thanks for the midi implementation Paul.
Waiting for Ardour 3

panning isn't possible yet.

panning isn't possible yet. still trying to decide on the right design for this. we probably need a "balance"-style control to supplement the per-channel panners, so that you can do "single knob" control.

Ok, then I've used what I

Ok, then I've used what I believe are standard XML comments to comment out the panning lines in my map file. I've also attempted to comment the file clearly so that people reading it should be able to easily tell what the intended controls are.

The result is at

I hope this will be useful ... Please let me know if any of what I've done will cause difficulty. I'm certainly willing to make adjustments. As noted earlier, I don't have Ardour-3 installed on my system, so this is untested.

@therockgarden: great stuff.

@therockgarden: great stuff. there was one minor error - the syntax is uri= not uri-, but i fixed that. Your map and joegiampoli's one for the oxygen 8 are now in svn, and hopefully there will be more to come. I will add some for the presets on my pc1600x, which actually correspond to other devices.

Thanks for spotting the

Thanks for spotting the error, Paul.

I noticed that I'd made similar errors with function= and sysex=. The copy at the above URL now has all of these corrected.

I have trouble compiling

I have trouble compiling Ardour3 at the moment because of my Hardy based system, but I will upgrade and contribute as soon as I can complete my current project. DDX3216.

@ qharley: You can do this

@ qharley:

You can do this with ardour 2; If you read above, Paul specifies a note:

"(Note: in Ardour3, you get a dedicated, custom dialog for this kind of tracing) "

Right below on how to have the terminal show you the message tracing. I did mine on Ardour 2 and Hardy.

Great... I'll start as soon

Great... I'll start as soon as I finish installing 64 Studio 3.3 alpha 2 (not for the faint hearted yet...)

ctl= is the number of midi

ctl= is the number of midi cc?
in your example, how define the route for gain to track?(i don't understand what is B1, is a bus? and B1 1 for example, what it this?you can refer to me some documentation if prefers)

@bocho999: the article your

@bocho999: the article your comment is attached to is the current documentation. If its not clear then i'd suggest just leaving it for now. if you have details about the MIDI messages sent by a controller, pass them along.

Here's a controller mapping

Here's a controller mapping for the Roland SI-24, as well as a photo of the board:

...and the owner's manual if anyone's interested:

Every controller number has been identified but I've commented out the majority of the bindings because it's still a little unclear how they should be mapped in Ardour. The device was designed to integrate specifically with Logic, ProTools, and Cubase, so some retrofitting is necessary.

For example, the pan pots and jog wheel don't generate CC messages; they output a Note On with a value of 1 for a single clockwise tick and 127 for counter-clockwise. Ardour's pan controls expect a CC message, so the SI-24's panner only ends up toggling between 100% left and 100% right. I'm not sure how to map the jog wheel to Ardour's timeline or shuttle controller, although it looks like this is possible with the Frontier Tranzport.

Also, rather than giving each track its own dedicated solo, mute, record enable, automation read/write, and surround pan control (which would have added to the cost of manufacturing), Roland only gave each track a status button. Toggling one of these features involves switching the status mode (mute, solo, rec/play, automix), then pressing the track's status button. That involves two button presses. However, the Ardour bindings are one-to-one. To make the device function as it was designed, I think the MIDI data would need to be piped through a filter before connecting it to Ardour's 0:control port in qjackctl.

@duffrecords: really nice

@duffrecords: really nice work.

Panning is currently not possible because of the design of Ardour's panning system. Ardour has 1 panning control per channel reaching the output of a track/bus, so there is no clear way to refer to "the panner" of a given track. We need to provide something like a "balance" control instead, so that there is a clear "endpoint" when trying to control panning. For a pathological case, consider a 1in/2out track that has a 1in/2out reverb plugin. Ardour provides a panning control for each channel coming out of the reverb. Remove the reverb, the track now has only 1 panning control. Complicated.

The status button design sounds awful :) However, its not impossible to imagine adding 2 new functions so that you could bind the status mode button to the function "status-switch" and then the other buttons to "status-mumble". Will consider it. Is this device still in production?

And yes, we need to figure out a way to define bindings for rotaries that behave like the pan pots on this device. Its not the only one to have this kind of design.

The SI-24 is now a legacy

The SI-24 is now a legacy product but the RPC-1 R-BUS card it utilizes is very similar to the ever-popular M-Audio Delta 1010LT. They both have 8 analog inputs/outputs, 1 S/PDIF in/out, 1 MIDI in/out, and use the Envy24 chipset.

folks, the update explains

folks, the update explains how it is now possible to include two new kinds of bindings, one involving an arbitrary MIDI message, the other invoking any of Ardour's (main) menu (and its submenus) items. This seems useful for some categories of controllers, as was discussed on IRC today.

Of course!!! sorry i don't

Of course!!! sorry i don't see this section in the article, i start working now.

ace! how about

ace! how about transport-forward and transport-backward bindings as well? that way a rotary dial could be used to navigate within a project.