jack-matchmaker 0.7.0

Examples

Automatically connect the first two ports of Fluidsynth to the audio outs using exact matching mode:

$ jack-matchmaker -e \
    fluidsynth:l_01 system:playback_1 \
    fluidsynth:r_01 system:playback_2

Both the output port and the input port patterns can be regular expressions. If a match is found on an output port, the matching port will be connected to all input ports, which match the corresponding input port pattern:

$ jack-matchmaker \
    'fluidsynth:l_\d+' 'system:playback_[13]' \
    'fluidsynth:r_\d+' 'system:playback_[24]'

You can also use named regular expression groups in the output port pattern and fill the port name sub-strings they match to into placeholders in the input port pattern:

$ jack-matchmaker \
    'system:midi_capture_(?P<num>\d+)$' 'mydaw:midi_in_track_{num}'

Regular expression and exact matching

By default port name patterns are always interpreted as Python regular expressions and are matched against port names, aliases and pretty-names using case-sensitive matching. They are anchored to the start of the string they match, i.e. they must match the start of the port name, but they still match, if the port name continues after the part the pattern matches.

E.g. the pattern client:out_\d matches client:out_1, client:out_2 etc. and also client:out_10 (even though the trailing zero is not included in the pattern), but does not match otherclient:out_1.

You can still match port names with arbitrary prefixes by using .* at the start of the pattern, e.g. .*client:out_\d.

To anchor the pattern to the end of the matched string as well, use a $ at the end of the pattern. E.g client:out_[12]$ will match client:out_1 and client:out_2, but not client:out_10, client:out_21 etc.

To use exact string matching instead of regular expression matching, use the -e, --exact-matching command line option. When this option is given, patterns must match port names (or aliases or pretty-names) exactly. You can still use regular expression patterns by enclosing a pattern in forward slashes, e.g. like so:

$ jack-matchmaker -e system:capture_1 '/myclient:in_l_\d+/'

All this applies to pattern given as positional command line arguments and to patterns listed in a pattern file (see below).

Pattern match group substitution

An output port pattern can contain one or more named groups with the syntax (?P<name>...), where the three dots represent a sub regular expression. The part of the port name matched by this sub regex, is available as a substitution value for a placeholder corresponding to the name of group in the input port pattern. Placeholders use the Python string formatting syntax.

Example:

$ jack-matchmaker \
    'mysynth:out_(?P<channel>[lr])_\d+$' 'myfx:in_{channel}$'

This would connect all ports named mysynth:out_l_1, mysynth:out_l_2 and so on to myfx:in_l and all ports named mysynth:out_r_1, mysynth:out_r_2 and so on to myfx:in_r.

Pattern files

In addition to or instead of listing port patterns as as positional arguments on the command line, port patterns can also be put in a text file.

The -p, --pattern-file option instructs the program to read the patterns from the file path given as the option value. The file must list one port pattern per line, where the first line of every pair of two lines specifies the output port pattern, and the second specifies the input port pattern. Empty lines and lines starting with a hash-sign (#) are ignored and whitespace at the start or the end of each line is stripped.

Example file:

# Left channel
# This will match output ports of any client named
# 'out_1', 'out_l', 'output_1' or 'output_l'
.*:out(put)?_(1|l)$
    system:playback_1

# Right channel
# This will match output ports of any client named
# 'out_2', 'out_r', 'output_2' or 'output_r'
.*:out(put)?_(2|r)$
    system:playback_2

# Another common naming scheme for output ports:
.*:Out L
    system:playback_1

.*:Out R
    system:playback_2

When you send a HUP signal to a running jack-matchmaker process, the file that was specified on the command line when the process was started is re-read and the resulting patterns replace all previously used patterns (including those listed as positional command line arguments!). If there should be an error reading the file, the pattern list will then be empty.