6 Jul
2014
6 Jul
'14
6:02 p.m.
Hello new to this list but realized I was asking a lot of development
questions in LAU that would probably be better here.
I am writing a program that takes some system input from the keyboard and
redirects it as midi. This is to allow:
- a second keyboard to be used as a midi control
- switching the system keyboard back and forth between normal and midi
controler
- using a potion of the system keyboard as a midi controler (the numeric
pad for example)
The advantage of this over keyboard short cuts is that this will work the
same no matter what the desktop focus may be.
I am (as many people do) writing this for my own use, but will make it
available for others who may have similar needs.
My question:
Where and how is the best place to put the MIDI port?
My first thought was to get it to create a jack midi port as this would be
the most direct. The problems I see with this are, 1) my program will run
as a different user than Jackd, 2) my program will run before and perhaps
after jackd.
SO then I thought I guess I have to use ALSA for my midi port. I need to
know if I do this, will jackd that is running a different backend than
alsa (firewire for example) still see the alsa midi ports? I am guessing
that a2jmidid would still work in any case, but not everyone uses that.
Assuming I have to use alsa midi (unless some one can suggest how to make
this work with jack midi), I have noticed that some aplications that use
alsa midi do not leave a visible port in alsa and do all connections
internally which would be useless in this case. There are some examples of
code at http://www.tldp.org/HOWTO/MIDI-HOWTO-9.html and I was wondering if
this method will leave visible midi ports. I am also noticing it 2004 ish,
is the info still valid, or is there a better place to look?
The keyboard input and grabbing will be based on the code from actkbd as
it seems to already do all that stuff and is gpl2 (and besides the code
looks understandable to me)
--
Len Ovens
www.ovenwerks.net
6 Jul
6 Jul
6:29 p.m.
On Sun, Jul 6, 2014 at 11:57 AM, Len Ovens <len(a)ovenwerks.net> wrote:
Hello new to this list but realized I was asking a lot
of development
questions in LAU that would probably be better here.
I am writing a program that takes some system input from the keyboard and
redirects it as midi. This is to allow:
- a second keyboard to be used as a midi control
- switching the system keyboard back and forth between normal and midi
controler
- using a potion of the system keyboard as a midi controler (the numeric pad
for example)
The advantage of this over keyboard short cuts is that this will work the
same no matter what the desktop focus may be.
I am (as many people do) writing this for my own use, but will make it
available for others who may have similar needs.
You might want to take a look at some previous implementations of
similar ideas (using console keyboard for MIDI). They use the ALSA
sequencer, I believe
http://vmpk.sourceforge.net/
http://alsa.opensrc.org/Vkeybd
--
Brett W. McCoy -- http://www.brettwmccoy.com
------------------------------------------------------------------------
"In the rhythm of music a secret is hidden; If I were to divulge it,
it would overturn the world."
-- Jelaleddin Rumi
6:49 p.m.
On Sun, 6 Jul 2014, Brett McCoy wrote:
You might want to take a look at some previous
implementations of
similar ideas (using console keyboard for MIDI). They use the ALSA
sequencer, I believe
http://vmpk.sourceforge.net/
http://alsa.opensrc.org/Vkeybd
Some of that code will be useful, but both of these run in user space and
use the Xorg keyboard inputs. This means that if I have a synth connected
to virtual kb, as soon as I try to change the synth patch, I loose my
virtual keyboard access because keyboard follows focus to the synth
application (which is what we want almost always). That is why I have to
run as a system user.
--
Len Ovens
www.ovenwerks.net
6:58 p.m.
On 07/06/2014 06:44 PM, Len Ovens wrote:
On Sun, 6 Jul 2014, Brett McCoy wrote:
http://lsmi-all.sourceforge.net/
You might want to take a look at some previous
implementations of
similar ideas (using console keyboard for MIDI). They use the ALSA
sequencer, I believe
http://vmpk.sourceforge.net/
http://alsa.opensrc.org/Vkeybd
Some of that code will be useful, but both of these run in user space
and use the Xorg keyboard inputs. This means that if I have a synth
connected to virtual kb, as soon as I try to change the synth patch, I
loose my virtual keyboard access because keyboard follows focus to the
synth application (which is what we want almost always). That is why I
have to run as a system user.
7 Jul
7 Jul
4:12 a.m.
On Sun, 6 Jul 2014, Jeremy Jongepier wrote:
This would be the closest starting point. Might even be enough for my own
use, but it seems, from the compile errors, the alsa api has changed. The
web page also gives some good tips on running it as a user. The last date
on the web page is 2007, has the alsa interface changed since then?
Anyway, this code looks like the best place yet to start from. actkbd will
have any bits missing on the kbd end and the alsa docs should have the
rest.
--
Len Ovens
www.ovenwerks.net
6 Jul
6 Jul
7:16 p.m.
On Sunday 06 July 2014 09:44:57 Len Ovens wrote:
On Sun, 6 Jul 2014, Brett McCoy wrote:
VMPK has an option (Edit->Preferences):
[x] Grab Computer Keyboard
If you enable this option, VMPK grabs keyboard events no matter which
application has the focus. It will be temporarily disabled when you minimize
VMPK's main window, and re-enabled when restoring it again. It is also
disabled when you open a dialog.
To do so in X11 applications you only need to invoke the XGrabKeyboard
function: http://www.x.org/archive/X11R7.5/doc/man/man3/XGrabKeyboard.3.html
There may be problems using this function in your program while running other
gtk+ based programs at the same time, because it is used by gtk+ menus as
well.
Regards,
Pedro
You might want to take a look at some previous
implementations of
similar ideas (using console keyboard for MIDI). They use the ALSA
sequencer, I believe
http://vmpk.sourceforge.net/
http://alsa.opensrc.org/Vkeybd
Some of that code will be useful, but both of these run in user space and
use the Xorg keyboard inputs. This means that if I have a synth connected
to virtual kb, as soon as I try to change the synth patch, I loose my
virtual keyboard access because keyboard follows focus to the synth
application (which is what we want almost always). That is why I have to
run as a system user.
7 Jul
7 Jul
1:50 a.m.
On Sun, 6 Jul 2014, Pedro Lopez-Cabanillas wrote:
On Sunday 06 July 2014 09:44:57 Len Ovens wrote:
So not very global.
use the Xorg keyboard inputs. This means that if
I have a synth connected
to virtual kb, as soon as I try to change the synth patch, I loose my
virtual keyboard access because keyboard follows focus to the synth
application (which is what we want almost always). That is why I have to
run as a system user.
VMPK has an option (Edit->Preferences):
[x] Grab Computer Keyboard
If you enable this option, VMPK grabs keyboard events no matter which
application has the focus. It will be temporarily disabled when you minimize
VMPK's main window, and re-enabled when restoring it again. It is also
disabled when you open a dialog.
To do so in X11 applications you only need to invoke the XGrabKeyboard
function: http://www.x.org/archive/X11R7.5/doc/man/man3/XGrabKeyboard.3.html
There may be problems using this function in your program while running other
gtk+ based programs at the same time, because it is used by gtk+ menus as
well.
So that makes it pretty much not usable for my use. I will have to catch
it before X does.... or set X up to look at only one keyboard. I want it
to be as solid as any HW midi controler, not half there.
By doing it early on, it is possible to only catch some of the keyboard
and not the whole thing. The numberic key pad on most keyboards is
redundant as all of the keys can be be gotten somewhere else. In that case
the numlock key can be used to switch midi mode in and out. Many Numeric
pads still have the non-numeric symbols on them that might work well for
transport control. Quite easy to only affect a second keyboard.
In fact for my own use I will be using a second keyboard (or it's board at
least). This is not quite so nice as something that looks like a standard
USB midi device, but that is what I am trying first. I am also looking at
various midi controler brains (or plans) that are available as I may go
that route for faders.
--
Len Ovens
www.ovenwerks.net
5:55 a.m.
It sounds to me like a keylogger as the input + MIDI (Jack or ALSA) as
output. Maybe a ring buffer or something in between.
If a keylogger is the kind of input you wish:
https://www.thc.org/papers/writing-linux-kernel-keylogger.txt
Trying to guess a naive code implementation, I foresee two problems:
- If one press a key and keep it pressed, the computer keyboard
repeeeeeeeeeeeeeeeeeeeeat the key, generating several NOTE_ON midi
events.
- Without a high level API I don´t know if you will have a KEY_RELEASE
event to generate a NOTE_OFF event. If you have it you can solve the
former problem.
Cheers
Schiavoni
Em 06-07-2014 12:57, Len Ovens escreveu:
Hello new to this list but realized I was asking a lot
of development
questions in LAU that would probably be better here.
I am writing a program that takes some system input from the keyboard
and redirects it as midi. This is to allow:
- a second keyboard to be used as a midi control
- switching the system keyboard back and forth between normal and midi
controler
- using a potion of the system keyboard as a midi controler (the
numeric pad for example)
The advantage of this over keyboard short cuts is that this will work
the same no matter what the desktop focus may be.
I am (as many people do) writing this for my own use, but will make it
available for others who may have similar needs.
My question:
Where and how is the best place to put the MIDI port?
My first thought was to get it to create a jack midi port as this
would be the most direct. The problems I see with this are, 1) my
program will run as a different user than Jackd, 2) my program will
run before and perhaps after jackd.
SO then I thought I guess I have to use ALSA for my midi port. I need
to know if I do this, will jackd that is running a different backend
than alsa (firewire for example) still see the alsa midi ports? I am
guessing that a2jmidid would still work in any case, but not everyone
uses that.
Assuming I have to use alsa midi (unless some one can suggest how to
make this work with jack midi), I have noticed that some aplications
that use alsa midi do not leave a visible port in alsa and do all
connections internally which would be useless in this case. There are
some examples of code at http://www.tldp.org/HOWTO/MIDI-HOWTO-9.html
and I was wondering if this method will leave visible midi ports. I am
also noticing it 2004 ish, is the info still valid, or is there a
better place to look?
The keyboard input and grabbing will be based on the code from actkbd
as it seems to already do all that stuff and is gpl2 (and besides the
code looks understandable to me)
--
Len Ovens
www.ovenwerks.net
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
8:59 a.m.
On Mon, 7 Jul 2014, Flávio Schiavoni wrote:
It sounds to me like a keylogger as the input + MIDI
(Jack or ALSA) as
output. Maybe a ring buffer or something in between.
If a keylogger is the kind of input you wish:
https://www.thc.org/papers/writing-linux-kernel-keylogger.txt
Key logger yes, but not built into the kernel... I remember rolling a
kernel with the install (before modules showed up) and for every update
too, but I already have examples that work after the kernel, but before X.
Trying to guess a naive code implementation, I foresee
two problems:
- If one press a key and keep it pressed, the computer keyboard
repeeeeeeeeeeeeeeeeeeeeat the key, generating several NOTE_ON midi
events.
Yes, that can be generated inside the kb. And as I want to use a USB Kb,
it could be worse. I think the typmatic rate can be changed though... Yup,
if X can turn it off, so can I. actkbd allows setting changes based on key
up or down.
- Without a high level API I don´t know if you will
have a KEY_RELEASE
event to generate a NOTE_OFF event. If you have it you can solve the
former problem.
According to what I have read (I may be wrong, or it may not apply to all
KB) when the kb repeats it sends both on and off. So turning it off seems
like a good idea.
I wasn't thinking of making a synth kb to turn notes off and on, but some
of the sw seems to do that just fine, X based or event based.
I want to do this in steps:
- Use a laptop extra number kb for transport control.
- Split the system kb to do the same thing
- play with a second keyboard see if I can get encoders to make sense.
This is the hardware I have on hand. If it works the way I want I will try
further mods. The LSMI project puts it into words better than I do. It
also says old AT kb are best.... I have one, but do not want break it
because the touch is so nice, I have been buying MB that it will work
with. USB kb are cheap at $3 if you know where to look. I can afford to
break one. I will never be able to press all the keys at the same time,
there will many key combinations that will not work too, but there may be
still a lot of uses for it.
The big thing is it will teach me more about code and the system. I could
just go and buy a midi controler.
--
Len Ovens
www.ovenwerks.net
5:57 p.m.
Great! I dunno if you need to argue about why to develop it because it
sounds to me a nice project.
You are right about the key_press / key_release events, a kb can trigger
both.
You said you already know how to capture kb events without a kernel
module.
Do you need to run it with sudo?
I'm asking it to try to help with your other doubt involving Jack MIDI
or ALSA MIDI.
Here goes my 3 cents.
If you need to run it with sudo, maybe the best approach is to divide
the system in a client / server paradigm.
One part is the kb event capture, running with sudo, and the other one
to generate MIDI events, in user space, no matter which API is used.
You can use RPC, DBUS or a UDP socket in localhost to exchange data
between both parts.
So, a kb event capture daemon will act as a server getting kb events and
sending it through a UDP connectionless socket, for instance.
It is fast enough.
The Jack / ALSA MIDI part will act as a client listening the UDP port,
capturing the kb events and generating the MIDI event.
The user will have to start the daemon (server) with sudo and the client
in user space and maybe you can have a nice app granting the user a
choice between ALSA or JACK implementation.
Best regards!
Schiavoni
Em 07-07-2014 03:54, Len Ovens escreveu:
On Mon, 7 Jul 2014, Flávio Schiavoni wrote:
It sounds to me like a keylogger as the input +
MIDI (Jack or ALSA) as
output. Maybe a ring buffer or something in between.
If a keylogger is the kind of input you wish:
https://www.thc.org/papers/writing-linux-kernel-keylogger.txt
Key logger yes, but not built into the kernel... I remember rolling a
kernel with the install (before modules showed up) and for every
update too, but I already have examples that work after the kernel,
but before X.
Trying to guess a naive code implementation, I
foresee two problems:
- If one press a key and keep it pressed, the computer keyboard
repeeeeeeeeeeeeeeeeeeeeat the key, generating several NOTE_ON midi
events.
Yes, that can be generated inside the kb. And as I want to use a USB
Kb, it could be worse. I think the typmatic rate can be changed
though... Yup, if X can turn it off, so can I. actkbd allows setting
changes based on key up or down.
- Without a high level API I don´t know if you
will have a KEY_RELEASE
event to generate a NOTE_OFF event. If you have it you can solve the
former problem.
According to what I have read (I may be wrong, or it may not apply to
all KB) when the kb repeats it sends both on and off. So turning it
off seems like a good idea.
I wasn't thinking of making a synth kb to turn notes off and on, but
some of the sw seems to do that just fine, X based or event based.
I want to do this in steps:
- Use a laptop extra number kb for transport control.
- Split the system kb to do the same thing
- play with a second keyboard see if I can get encoders to make sense.
This is the hardware I have on hand. If it works the way I want I will
try further mods. The LSMI project puts it into words better than I
do. It also says old AT kb are best.... I have one, but do not want
break it because the touch is so nice, I have been buying MB that it
will work with. USB kb are cheap at $3 if you know where to look. I
can afford to break one. I will never be able to press all the keys at
the same time, there will many key combinations that will not work
too, but there may be still a lot of uses for it.
The big thing is it will teach me more about code and the system. I
could just go and buy a midi controler.
--
Len Ovens
www.ovenwerks.net 
7 p.m.
On Mon, Jul 7, 2014 at 5:00 PM, Flávio Schiavoni <fls(a)rendera.com.br> wrote:
I'm asking it to try to help with your other doubt
involving Jack MIDI or
ALSA MIDI.
Here goes my 3 cents.
If you need to run it with sudo, maybe the best approach is to divide the
system in a client / server paradigm.
+1, with a note that the RtMidi library is probably the best way to
implement the MIDI backend, as it supports JACK, ALSA etc trough the same
high-level API: http://www.music.mcgill.ca/~gary/rtmidi/
HTH, -Harry
10 Jul
10 Jul
9:06 a.m.
On Mon, 7 Jul 2014, Flávio Schiavoni wrote:
You said you already know how to capture kb events
without a kernel
module.
Do you need to run it with sudo?
I'm asking it to try to help with your other doubt involving Jack MIDI
or ALSA MIDI.
Here goes my 3 cents.
If you need to run it with sudo, maybe the best approach is to divide
the system in a client / server paradigm.
One part is the kb event capture, running with sudo, and the other one
to generate MIDI events, in user space, no matter which API is used.
You can use RPC, DBUS or a UDP socket in localhost to exchange data
between both parts.
Right now, I have to sudo to run it. The author of
http://lsmi-all.sourceforge.net/ suggests:
"In order to be run by a non-root user the drivers must have access to
the device files in /dev/input. This may be accomplished by adding a group
'input', adding desired users to this group, and configuring udev to
assign the appropriate ownership to files in /dev/input. It should be
resonably safe to run the drivers as root, however."
lsmi uses alsa midi and so can be run as root from the startup scripts.
Adding an input group would allow running as user. Runnning as the user:
- allows using jack ports directly. Saves using through lines or a2j as
most DAW projects work with jack ports.
- allows the user to start/stop the application.
- allows the user to configure the keys.
- allows the application to use the screen for feed back.
I have used sockets for this stuff before, but would prefer not to. I am
going to figure out udev.
--
Len Ovens
www.ovenwerks.net
9:57 a.m.
On Thu, 10 Jul 2014 00:01:13 -0700 (PDT)
Len Ovens <len(a)ovenwerks.net> wrote:
I have used sockets for this stuff before, but would
prefer not to. I am
going to figure out udev.
--
Len Ovens
www.ovenwerks.net
Brave man!
Where do we send the flowers? :)
--
Will J Godfrey
http://www.musically.me.uk
Say you have a poem and I have a tune.
Exchange them and we can both have a poem, a tune, and a song.
11 Jul
11 Jul
2:39 a.m.
On Thu, 10 Jul 2014, Will Godfrey wrote:
On Thu, 10 Jul 2014 00:01:13 -0700 (PDT)
Len Ovens <len(a)ovenwerks.net> wrote:
Hacking udev turned out to be quite easy. created a file:
/lib/udev/rules.d/midikb.rules ( it should actually be 90-midikb.rules to
fit with all else, but it gets loaded after all else so it works this way
too) It has one line:
KERNEL=="event*", GROUP="input", MODE="0660"
And now after boot I have:
$ ls -l /dev/input/*
crw-rw---- 1 root input 13, 64 Jul 10 15:35 /dev/input/event0
crw-rw---- 1 root input 13, 65 Jul 10 15:35 /dev/input/event1
crw-rw---- 1 root input 13, 66 Jul 10 15:35 /dev/input/event2
crw-rw---- 1 root input 13, 67 Jul 10 15:35 /dev/input/event3
crw-rw---- 1 root input 13, 68 Jul 10 15:35 /dev/input/event4
crw-rw---- 1 root input 13, 69 Jul 10 15:35 /dev/input/event5
crw-rw---- 1 root input 13, 70 Jul 10 15:57 /dev/input/event6
crw-rw---- 1 root input 13, 71 Jul 10 15:58 /dev/input/event7
6 is my extra USB kb, 7 is part of it too, but I am not sure what... maybe
the missing keys from event6? (though why would U and I be separate?)
Anyway, event2 is my system ps/2 kb and event3 is the ps/2 mouse. Event4
is labeled platform-eeepc-wmi-event and I think event 5 is my power
button. (my system keyboard is an old AT ... with AT/XT switch even)
Anyway, actkbd -s -d /dev/input/event6 displays my scancodes like this:
Keys: 35
Keys: 34+35
The way it works (with these options and no config for actkbd) is that key
35 was pressed first and 34 after, but before 35 was released. If I then
release 35, then 34 shows on it's own. So each event (press or release)
shows what keys are still active. I do not have "grab" turned on and so
the actual key press is still being fed to Xorg as well. I can hold the
key long enough for repeat to start for Xorg, but actkbd does not show all
of the repeats, just the original key press. I do not know if this is
unique to USB kb or works with AT kb as well. ps/2 keyboards have three
modes, 1 = xt (not used) 2 = at (everything can do this) 3 = ps/2 (more
options such as turning typematic off) Not sure what USB does, but it
probably looks like a ps/2 to be able to work at boot time.
--
Len Ovens
www.ovenwerks.net
I have used sockets for this stuff before, but
would prefer not to. I am
going to figure out udev.
Brave man!
Where do we send the flowers? :)
3981
days inactive
3986
days old
linux-audio-dev@lists.linuxaudio.org
13 comments
7 participants
participants (7)
-
Brett McCoy -
Flávio Schiavoni -
Harry van Haaren -
Jeremy Jongepier -
Len Ovens -
Pedro Lopez-Cabanillas -
Will Godfrey