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

_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Reply via email to