midizap/example.midizaprc

# Copyright 2013 Eric Messick (FixedImagePhoto.com/Contact)
# Copyright 2018 Albert Graef <aggraef@gmail.com>
#
# Lines in this file starting with # are comments.

# This program works pretty much like Eric Messick's shuttlepro program,
# but it translates MIDI input rather than input events from the Contour
# Design Shuttle devices.  By default, the program creates a Jack MIDI
# client named "midizap" with a single input port, which you'll have to
# connect to the MIDI controller that you want to use (e.g., using a
# patchbay program like qjackctl; non-Jack ALSA MIDI inputs can be
# accommodated using a2jmidid).

# Both the Jack client name and the number of (input and output) ports
# can be adjusted, either from the command line, using the -j and -o
# options (these always take priority), or by employing the following
# midizaprc directives.  NOTE: These options only take effect
# immediately after program start, when the Jack client is initialized.
# If you edit them later, you need to restart the program, so that a new
# Jack client is created.

# The JACK_NAME directive is used to change the client name.
# (Uncomment the line and edit the name as needed.)  This is useful,
# e.g., if you're running multiple instances of midizap using different
# configurations for different controllers, and you want to have them
# named appropriately so that they can be wired up more easily using the
# qjackctl patchbay.

#JACK_NAME "midizap"

# The number of ports given with the JACK_PORTS directive must be
# 1 or 2.  It causes the given number of both input and output ports to
# be created.  This option is useful if you want to translate MIDI
# messages, see the [MIDI] section below for details.  Two input and
# output ports can be employed, e.g., if you also need to provide
# backward translations for controller feedback, see the [MIDI2] section
# below for an example.

#JACK_PORTS 2

# Other than the input being MIDI instead of the Shuttle's key and wheel
# events, the program works like Eric Messick's original.  Each section
# in the file (starting with a name in brackets and a regex to be
# matched against the window class and name) specifies the bindings for
# one application.  A section at the end without regex provides default
# bindings if none of the other sections are matched.  Within each
# section, bindings are introduced with the name of the MIDI message
# being assigned, followed by a sequence of X KeySyms and/or MIDI
# messages to be output when the MIDI message is received.

# Here is a brief rundown of the supported notation for MIDI messages
# (please check the documentation for details).

# CC<0..127>: control change message for the given controller
# PC<0..127>: program change message
# PB: pitch bend message
# CP: channel pressure
# KP:<note>: key pressure (aftertouch)
# <A..G><#b><num>: MIDI note (on or off)

# Note messages are specified using the customary notation (note name
# A..G, optionally followed by an accidental, # or b, followed by a MIDI
# octave number).  The same notation is also used with aftertouch (KP)
# messages, which always apply to a specific note (in contrast, channel
# pressure (CP) always applies to all notes on a single MIDI channel).
# Enharmonic spellings are equivalent, so, e.g., D#5 and Eb5 denote
# exactly the same MIDI note.  All MIDI octaves start at the note C, so
# B0 comes before C1.  By default, octave numbers are zero-based, so C0
# is MIDI note 0, C5 denotes middle C, A5 is the chamber pitch, etc.
# However, you can adjust this to your liking by specifying the offset
# of the lowest MIDI octave.  Two of the most common alternatives are
# listed below (uncomment one of the following lines to use these):

#MIDI_OCTAVE -1 # ASA (Acoustical Society of America; middle C is C4)
#MIDI_OCTAVE -2 # alternate MIDI (various manufacturers; middle C is C3)

# The program distinguishes between messages on different MIDI channels.
# By default, messages are assumed to be on MIDI channel 1, but the MIDI
# channel can be specified explicitly following a dash at the end of the
# message token.  E.g., a message on MIDI channel 10 would be denoted
# CC7-10 or C#3-10.

# Each of these messages can be either "on" or "off", and so they can
# have different "press" and "release" keystrokes associated with them.
# In addition, all messages except PC (which doesn't have a data value)
# can also have their value changes translated, in which case they have
# associated key bindings which are executed each time the value
# increases or decreases, respectively.  Such bindings are indicated
# with the suffixes "+" and "-".  You can also use the "=" suffix to
# indicate that the same translation should be applied to both increases
# and decreases of the controller or pitch bend value.  Thus, e.g., CC7=
# indicates that the same translation applies for both CC7+ and CC7-.
# This is most commonly used with pure MIDI -> MIDI translations.

# There is also another special mode for these incremental bindings,
# incremental "bit-sign" mode.  The suffixes "<", ">" and "~" can be
# used in lieu of "+", "-" and "=" with the CC token to properly
# interpret the control values of endless rotary encoders and jog wheels
# on Mackie-like devices.  These encoders send values < 64 for
# increases, and > 64 for decreases, where the first 6 bits of the value
# denote the actual amount of change relative to the current value.

# Debugging options: You want to run the program in a terminal window to
# see its output when using these.  The following line, when
# uncommented, prints the section recognized for the window in focus:

#DEBUG_REGEX

# This option prints the contents of the entire configuration file, as
# parsed by the program, in a human-readable format:

#DEBUG_STROKES

# You can also use the following option to have the recognized
# translations printed out as the program executes them, in the same
# format as DEBUG_STROKES:

#DEBUG_KEYS

# Finally, the following option prints all MIDI input (with the input
# port number in the first, and the actual data value in the last
# column).  This is useful as a simple MIDI monitor, especially if you
# want to figure out which tokens to use in your translations.

#DEBUG_MIDI

# NOTE: The debugging options can also be specified on the command line
# using -d in conjunction with any of the letters r, s, k and m (or the
# letter j if you also want debugging output from Jack).  Just -d
# without any option letter turns on all debugging options.


# Sample bindings for video editing.  These assume a Mackie-compatible
# device, which are available from various manufacturers.  They are more
# or less standardized, and offer an abundance of useful controls,
# making it easier to provide bindings which just work.  If you don't
# have one of these lying around, there are inexpensive emulations in
# software (such as the TouchDAW app on Android), or you can just edit
# the rules below to make them work with your controller.

# On most Mackie-like devices there are some playback controls and
# cursor keys which generate various note events, and a jog wheel which
# generates CC60 messages.  We put all of these to good use here.  Note
# that the CC60 control requires use of the aforementioned special
# incremental mode for endless rotary encoders.


# Bindings for the Kdenlive and Shotcut video editors (matched by their
# WM_CLASS).  These have very similar key bindings, see e.g.:
# https://www.shotcut.org/howtos/keyboard-shortcuts/

[Kdenlive/Shotcut] ^(shotcut|kdenlive)$

# Both Kdenlive and Shotcut use the J-K-L shortcuts, where each
# successive J or L key decrements or increments the playback speed.  We
# assign these to the MCU Rewind and Forward controls.

# playback controls
 A#7 XK_space    # Play/Pause
 A7  "K"         # Stop
 G7  "J"         # Rewind
 G#7 "L"         # Forward

# punch in/out (sets in and out points)
# Note that these are labeled drop/replace on some devices.  We also
# provide an alternative binding below.
 D#7 "I"         # Set In
 E7  "O"         # Set Out

# up/down cursor movement (alternate binding for set in/out)
 C8  "I"         # Set In
 C#8 "O"         # Set Out

# left/right cursor movement
 D8  XK_Home     # Beginning
 D#8 XK_End      # End

# the jog wheel moves left/right by single frames
 CC60< XK_Left    # Frame reverse
 CC60> XK_Right   # Frame forward


[MIDI]

# The special "MIDI" default section is only active when MIDI output is
# enabled (midizap -o).  This allows you to use midizap as a MIDI mapper
# translating MIDI input to MIDI output.  Here's a simple example for
# illustration purposes, which shows how to map both the Mackie master
# fader and the jog wheel to CC7, so that they can be used as volume
# controls.

# Note that the master fader is PB (on MIDI channel 9), which has 128
# times the range of a MIDI controller, so we scale it down accordingly
# by specifying a step size of 128.

 PB[128]-9= CC7
 CC60~      CC7

# Drumkit example.  The following translations should work on most MIDI
# keyboards.  We assume that the keyboard is set to MIDI channel 1 (the
# usual default).  The first four white keys (C, D, E and F) in the
# fourth MIDI octave are mapped to the notes of a little drumkit on MIDI
# channel 10, and the volume controller (CC7) is bound to the volume
# controller on the same channel, so that you can change the output
# volume as you play the drumkit.  Note that you need a GM-compatible
# software synthesizer such as Fluidsynth/Qsynth to make this work.

 C4    C3-10
 D4    C#3-10
 E4    D3-10
 F4    D#3-10

 CC7=  CC7-10


[MIDI2]

# Auxiliary MIDI translations.  This is only used when midizap is
# invoked with the -o2 option, so that it creates a second pair of MIDI
# input and output ports.  Input for this section only comes from the
# second input port, and output goes to the second output port.  This is
# typically used for feedback to controllers featuring motor faders,
# LEDs and the like, in which case the translations are often the
# inverse of what's in the [MIDI] section.

# Here we only map CC7 back to PB-9 (the MCU master fader).  Please
# check examples/APCmini.midizaprc for a more comprehensive example.

 CC7= PB[128]-9


# Default section (cursor and mouse emulation)

[Default]

# First, some Mackie-compatible bindings.

# cursor movement
 D8    XK_Left
 D#8   XK_Right
 C8    XK_Up
 C#8   XK_Down

# stop/play/rec are assigned to the left/middle/right mouse buttons
 A7    XK_Button_1
 A#7   XK_Button_2
 B7    XK_Button_3

# the jog wheel emulates the scroll wheel of the mouse
 CC60< XK_Scroll_Up
 CC60> XK_Scroll_Down

# The following bindings should work on any MIDI keyboard.  The C, D and
# E keys in the middle octave are bound to the three mouse buttons, and
# the modulation wheel (CC1) emulates the mouse wheel.  The F, G, A and
# B keys in the middle octave are mapped to the cursor keys (Left, Up,
# Down, Right).

 C5    XK_Button_1
 D5    XK_Button_2
 E5    XK_Button_3

 F5    XK_Left
 G5    XK_Up
 A5    XK_Down
 B5    XK_Right

 CC1+  XK_Scroll_Up
 CC1-  XK_Scroll_Down