X-Git-Url: http://shamusworld.gotdns.org/cgi-bin/gitweb.cgi?a=blobdiff_plain;f=include%2Fgeneric-midi-binding-maps.html;h=47758a2bf038520f90a1290d9734202c5db10f99;hb=f56f685d73572cad74ad34f4b9dc8acf5ed68fdf;hp=43d56a115ba267885d37d376bc021ba3597f3bf8;hpb=2098e011e638b5c86c56e68df7757975fc4d728f;p=ardour-manual diff --git a/include/generic-midi-binding-maps.html b/include/generic-midi-binding-maps.html index 43d56a1..47758a2 100644 --- a/include/generic-midi-binding-maps.html +++ b/include/generic-midi-binding-maps.html @@ -1,7 +1,7 @@

Ardour 2.X supported - MIDI learning + MIDI learning for more or less any control. This was a nice feature that quite a few other DAWs are providing by now, but it didn't allow Ardour to work "out of the box" with sensible defaults for existing commercial MIDI @@ -53,8 +53,7 @@ remote control ID. This ID uniquely identifies a track or bus so that when messages arrive from elsewhere via MIDI or OSC , we can determine which track or bus they are intended to control. See - + remote control IDs for more information. You just need to know that there is a "first track" and its remote control ID is 1, and so on. @@ -106,8 +105,8 @@ bindings"> A track/bus binding has one of two basic structures

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

Message specifications

@@ -117,7 +116,7 @@ bindings"> like this:

- <Binding channel="1" ctl="13" .... + <Binding channel="1" ctl="13" ….

This defines a binding for a MIDI Continuous Controller message involving @@ -132,7 +131,7 @@ bindings"> offsets rather than values. These accept Continuous Controller messages but treat them as offsets. These are good for banked controls as they are always at the right spot to start adjusting. ( - + Learn more about working with encoders )

@@ -140,8 +139,8 @@ bindings"> You can also bind sysex messages:

- <Binding sysex="f0 0 0 e 9 0 5b f7" .... - <Binding sysex="f0 7f 0 6 7 f7" .... + <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, @@ -150,8 +149,8 @@ bindings">

Finally, you can bind a totally arbitrary MIDI message:

- <Binding msg="f0 0 0 e 9 0 5b f7" .... - <Binding msg="80 60 40" .... + <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 @@ -178,46 +177,46 @@ bindings"> A control address defines what the binding will actually control. There are quite a few different things that can be specified here:

-
-
/route/gain
-
the gain control ("fader") for the track/bus
-
/route/trim
-
the trim control for the track/bus (new in 4.1)
-
/route/solo
-
a toggleable control for solo (and listen) of the track/bus
-
/route/mute
-
a toggleable control to mute/unmute the track/bus
-
/route/recenable
-
a toggleable control to record-enable the track
-
/route/panwidth
-
interpreted by the track/bus panner, should control image "width"
-
/route/pandirection
-
interpreted by the track/bus panner, should control image "direction"
-
/route/plugin/parameter
-
the Mth parameter of the Nth plugin of a track/bus -
-
/route/send/gain
-
the gain control ("fader") of the Nth send of a track/bus
-
+ + + + + + + + + + + + + + + + + + + +
/route/gainthe gain control ("fader") for the track/bus
/route/trimthe trim control for the track/bus (new in 4.1)
/route/soloa toggleable control for solo (and listen) of the track/bus
/route/mutea toggleable control to mute/unmute the track/bus
/route/recenablea toggleable control to record-enable the track
/route/panwidthinterpreted by the track/bus panner, should control image "width"
/route/pandirectioninterpreted by the track/bus panner, should control image "direction"
/route/plugin/parameterthe Mth parameter of the Nth plugin of a track/bus +
/route/send/gainthe gain control ("fader") of the Nth send of a track/bus

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) -
-
S, followed by a number -
-
identifies a selected track in order they have been selected, S1 should be the same track as the Editor Mixer -
-
one or more words -
-
identifies a track or bus by its name -
-
+ + + + + + + + + +
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) +
S, followed by a number +identifies a selected track in order they have been selected, S1 should be the same track as the Editor Mixer +
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 @@ -228,7 +227,7 @@ bindings">

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 + 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.

@@ -246,64 +245,64 @@ bindings"> In this case, a NoteOn message for note number 13 (on channel 1) will start the transport rolling. The following function names are available:

-
-
+ + + + + + + + + + + + + + + + + + + + + +
transport-stop - -
stop the transport -
-
+
stop the transport +
transport-roll - -
start the transport "rolling" -
-
+
start the transport "rolling" +
transport-zero - -
move the playhead to the zero position -
-
+
move the playhead to the zero position +
transport-start - -
move the playhead to the start marker -
-
+
move the playhead to the start marker +
transport-end - -
move the playhead to the end marker -
-
+
move the playhead to the end marker +
loop-toggle - -
turn on loop playback -
-
+
turn on loop playback +
rec-enable - -
enable the global record button -
-
+
enable the global record button +
rec-disable - -
disable the global record button -
-
+
disable the global record button +
next-bank - -
Move track/bus mapping to the next bank (see Banks below) -
-
+
Move track/bus mapping to the next bank (see Banks below) +
prev-bank - -
Move track/bus mapping to the previous 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 + href="@@list-of-menu-actions"> list of actions shows all available values of action-name.

To create a binding between an arbitrary MIDI message (we'll use a @@ -326,7 +325,7 @@ bindings"> for far fewer tracks & busses than many users want to control, Ardour offers the relatively common place concept of banks. Banks allow you to control any number of tracks and/or busses easily, - regardless of how many faders/knobs etc. your control surface has.
+ 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 @@ -389,5 +388,3 @@ bindings"> (the channel range may change at some point).

-{% children %} -