forked from agraef/ShuttlePRO
-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathexample.shuttlerc
264 lines (208 loc) · 10 KB
/
example.shuttlerc
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
# Copyright 2013 Eric Messick (FixedImagePhoto.com/Contact)
# Copyright 2018 Albert Graef <[email protected]>
#
# Lines in this file starting with # are comments.
# This file is divided into paragraphs, each specifying the bindings to
# be used when the keyboard focus is on a specific window. The
# paragraph is introduced with a line starting with [. That line
# contains the paragraph name (which is only used for debugging output
# to help you in editing this file) followed by ], followed by a regular
# expression. When the class or name of the focused window matches the
# regular expression (see regex(7)), the bindings in the paragraph will
# be in effect. The program tries these regular expressions in order,
# and the first match is used. It first tries to match the class
# (WM_CLASS property) of the window, since that usually provides the
# better clues for identifying an application. If that fails, it will
# then also try to match the window's title (WM_NAME property).
# NB: Try to be as specific with the regular expression as possible, in
# order to prevent accidental matches. Often an application uses its
# name as the class name or in its title bar, in which case finding a
# suitable regex should be relatively easy. See below for some
# examples.
# If there is no regex on the line, like the [Default] line near the
# bottom, the paragraph acts as a default. Any window class and title
# which does not match any regex will use the default bindings. Any
# keys which are not specified in the paragraph which does match will
# use the default bindings for those keys.
# While you are working on regular expressions to match your window
# names, is is useful to see the window names and classes, as well as
# the paragraph names which the program finds as you generate ShuttlePRO
# events. Run the shuttle program in a terminal window and remove the
# comment character from the following line:
#DEBUG_REGEX
# Within a paragraph, key bindings are introduced with the name of the
# key or event being defined. Keys are named K1 through K15. Positions
# of the shuttle wheel are named S-7 through S-1 for counter-clockwise
# positions, S0 for the rest position in the center, and S1 through S7
# for the clockwise positions. The jog wheel emits two events named JL
# and JR, for counter-clockwise and clockwise rotations respectively.
# Some programs may expect the shuttle wheel to work like a secondary
# jog wheel. To accommodate these, key bindings can also be specified
# using the incremental shuttle events IL and IR, which indicate
# counter-clockwise and clockwise rotations, and work in the same
# fashion as the jog wheel (albeit with a limited range of -7 .. 7).
# The keys on the Contour Shuttle Pro v2 are arranged like this:
#
# K1 K2 K3 K4
# K5 K6 K7 K8 K9
#
# K14 Jog K15
#
# K10 K11
# K12 K13
# After the name of the key being bound, the remainder of the line is
# the sequence of X KeySyms which will be generated when that event is
# received. Look up the KeySyms in /usr/include/X11/keysymdef.h. In
# addition to the KeySym names found there, you can also use XK_Button_1
# for the left mouse button, XK_Button_2 for the middle mouse button,
# XK_Button_3 for the right mouse button, XK_Scroll_Up and
# XK_Scroll_Down for mouse scroll wheel events. For sequences of one or
# more printable characters, you can just enclose them in double quotes.
# Each KeySym you specify will be pressed and released before the next
# KeySym is pressed. If you wish a key to be held down, you can add a
# /D to the end of the KeySym. For example: XK_Shift_L/D,
# XK_Control_L/D or XK_Alt_L/D. Such keys will be held down until you
# specify they should be released with a /U on the same KeySym name.
# They will all be released at the end of the binding anyway, so you
# usually won't have to use /U.
# Key bindings, whose names start with a K, allow for some extra
# options. Since they generate separate events when pressed and
# released, you can control that as well. Each non-modifier key is
# pressed and released in sequence except for the last which is not
# released until the shuttle key is released. If you want to press more
# keys during the release sequence, you can put them after the special
# word "RELEASE". Modifier keys specified with /D are released at the
# end of the press sequence, and re-pressed if there are any keys to be
# pressed after RELEASE. If you don't want the modifier keys to be
# released (you want to use a ShuttlePRO key as Shift, for example) you
# can follow it with a /H instead of /D.
# It's also possible to translate events to MIDI messages, and output
# them via Jack MIDI. To these ends, just invoke the program with the
# -o (MIDI output) option. This will start Jack if it's not already
# running, and create a Jack MIDI client named "shuttlepro" with a
# single MIDI output port, which can be hooked up to other Jack MIDI
# applications in the usual way (e.g., using a patchbay program like
# qjackctl). In the translations, MIDI messages can be freely mixed
# with keypresses; the MIDI messages will be simply ignored if Jack MIDI
# output is not enabled.
# Here is a brief rundown of the supported MIDI messages (please check
# the manual for a much more detailed account with examples):
# CH<1..16>: sets the default output channel for subsequent MIDI messages
# CC<0..127>: outputs a control change message for the given controller
# PC<0..127>: outputs a program change message
# PB: outputs a pitch bend message
# <A..G><#b><0..10> (MIDI notes): outputs the given MIDI note (note on
# when pressed, note off when released)
# 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. Enharmonic spellings are equivalent, so, e.g., D# and
# Eb 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, and C5 denotes middle C. 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)
# If you want to see exactly how this file is parsed and converted into
# KeySym strokes and MIDI messages, run the shuttle program in a
# terminal window and remove the comment character from the following
# line:
#DEBUG_STROKES
# You can also use the following option to have the recognized key
# bindings printed out as the program executes them, in the same format
# as DEBUG_STROKES:
#DEBUG_KEYS
# NOTE: The debugging options can also be specified on the command line
# using -d in conjunction with any of the letters r, s and k (or the
# letter j if you also want debugging output from Jack). Just -d
# without any option letter turns on all debugging options.
# As one of the main reasons to use a ShuttlePRO is video editing, I've
# included a sample set of bindings for Cinelerra as an example.
[Cinelerra Resources] ^Cinelerra: Resources$
# use [Default], avoiding main Cinelerra rule
[Cinelerra Load] ^Cinelerra: Load$
# use [Default], avoiding main Cinelerra rule
[Cinelerra] ^Cinelerra: [^[:space:]]*$
K5 XK_KP_0 # Stop
K9 XK_KP_3 # Play
K12 XK_Home # Beginning
K13 XK_End # End
K14 "[" # Toggle in
K15 "]" # Toggle out
S-3 XK_KP_Add # Fast reverse
S-2 XK_KP_6 # Play reverse
S-1 XK_KP_5 # Slow reverse
S0 XK_KP_0 # Stop
S1 XK_KP_2 # Slow forward
S2 XK_KP_3 # Play forward
S3 XK_KP_Enter # Fast forward
JL XK_KP_4 # Frame reverse
JR XK_KP_1 # Frame forward
# Shotcut (WM_CLASS is "shotcut")
# see https://www.shotcut.org/howtos/keyboard-shortcuts/
[Shotcut] ^shotcut$
K7 XK_space # Play/Pause
K6 XK_Home # Beginning
K8 XK_End # End
K5 "I" # Set In
K9 "O" # Set Out
# In Shotcut the J and L shortcuts are accumulative, i.e., each
# successive J and L key decrements and increments the playback speed,
# respectively, with negative speeds indicating rewind, positive speeds
# fast forward. Thus we can simply treat the shuttle like a secondary
# jog wheel here.
IL "J" # Rewind
IR "L" # Forward
# The jog wheel moves single frames to the left or the right.
JL XK_Left # Frame reverse
JR XK_Right # Frame forward
# Kdenlive has its own built-in support for the Shuttle, but as the
# shuttlepro program blocks the device when it's running, we include
# some sensible bindings here anyway (pretty much the same as Shotcut
# above, but the shuttle bindings are a bit more complicated, as in
# contrast to Shotcut, the J and L keys aren't accumulative).
[Kdenlive] ^kdenlive$
K7 XK_space # Play/Pause
K6 XK_Home # Beginning
K8 XK_End # End
K5 "I" # Set In
K9 "O" # Set Out
S-3 "KJJJ" # Rewind+2
S-2 "KJJ" # Rewind+1
S-1 "KJ" # Rewind
S0 "K" # Stop
S1 "KL" # Forward
S2 "KLL" # Forward+1
S3 "KLLL" # Forward+2
JL XK_Left # Frame reverse
JR XK_Right # Frame forward
# The special "MIDI" default section is only active when MIDI output is
# enabled (shuttlepro -o).
[MIDI]
# Poor man's MCU. This emulates a Mackie-compatible device with playback
# controls (including fast forward/rewind, which are assigned to the
# shuttle) and a jog wheel. You can use this as a (rather rudimentary)
# Mackie control surface, e.g., with Ardour.
K6 A7 # Stop
K7 A#7 # Play
K8 B7 # Record
# K8 D7 # Cycle
# Move the cursor on the timeline.
K5 D8 # Left
K9 D#8 # Right
# Shuttle (fast forward/rewind/stop).
IL G7 # Rewind
IR G#7 # Fast Forward
S0 A7 # Stop
# The Mackie jog wheel is CC60, but it uses a special kind of encoding
# of relative controller values, indicated with the ~ suffix.
JL CC60~
JR CC60~
# Default (mouse emulation)
[Default]
K6 XK_Button_1
K7 XK_Button_2
K8 XK_Button_3
JL XK_Scroll_Up
JR XK_Scroll_Down