As refered to earlier, I am working on an app to use a standard computer
keyboard for DAW (or other) control. I have started with actkbd and am
moving from there. actkbd remains fully usable, but I have added things to
make it useful for control of DAW apps. My first attempt at jackd
interface was to allow keys to control the jack transport. The actions I
set up are:
roll
stop
zero
forward 1 sec (48kframes)
forward 10 seconds (480Kframes)
back 1 sec
back 10 sec
Because of how actkbd is set up, the key use for these is fully
configurable. I have been using the numeric keypad:
Enter = roll
0 = stop
+ = forward
+ repeat = fast forward
etc.
The repeat can be used or ignored. In the future I would like to set up
the forward and back so the user can configure the number of frames rather
than having just two choices, but I am more interested in proving the
concept first.
My next thing is to set up (jack)MIDI out (the port shows on the graph so
far :)
However, while testing this (with ardour as happens), I am wondering about
the merrits of using jack transport at all. That is, would it be better to
only use midi to control one application's control of the transport rather
than controling the transport directly? In this case the user would have
the option of which to use because they do not have to configure any keys
to send transport actions. But I am wondering if it would cause problems
that could be easily solved by not offering transport control at all.
Lots of things still to figure out:
- send unused keys to another system kb interface so X will grab it
(allows spliting the keyboard)
- output MIDI info on both jack and alsa.
- gracefully not use jack outputs if jack is not running
- detect jack showing up and start using jack outputs
- create some sample, but useful config files for those who don't want to
- create a GUI to make config files
So far, I have been using a second keyboard which is "grabbed" so tha X
doesn't see it.
--
Len Ovens
www.ovenwerks.net