28 Feb
2016
28 Feb
'16
12:18 p.m.
Hello,
Having some bare keyboards and raspberry-sortof boards, I'd be interested in
connecting both of them without using a midi interface, but only the available GPIO pins
available on the board. This is as well to save external components and as a programming
exercise.
After searching for information, nothing revelant was found, except a experimental python
script to read gpio and using the mididings library to output messages.
Is there a existing project which would scan rows/colums of a keyboard from the
designated(configured) gpios, and throw midi message to an alsa midi port ?
Would such a program better be a kernel module or a userland program ?
Thanks for your advice
Raphaël
28 Feb
28 Feb
1:49 p.m.
* Raphaël Mouneyres <rmouneyres(a)gmail.com> [2016-02-28 13:18]:
Hello,
Having some bare keyboards and raspberry-sortof boards, I'd be interested in
connecting both of them without using a midi interface, but only the available GPIO pins
available on the board. This is as well to save external components and as a programming
exercise.
After searching for information, nothing revelant was found, except a experimental python
script to read gpio and using the mididings library to output messages.
Is there a existing project which would scan rows/colums of a keyboard from the
designated(configured) gpios, and throw midi message to an alsa midi port ?
Pure
Data
2:29 p.m.
Pd-l2ork comes with I2s and gpio externals, including support for soft pwm
on all pins. HTH
--
Ivica Ico Bukvic, D.M.A.
Associate Professor
Computer Music
ICAT Senior Fellow
Director -- DISIS, L2Ork
Virginia Tech
School of Performing Arts – 0141
Blacksburg, VA 24061
(540) 231-6139
ico(a)vt.edu
www.performingarts.vt.edu
disis.icat.vt.edu
l2ork.icat.vt.edu
ico.bukvic.net
On Feb 28, 2016 8:49 AM, "Peter P." <peterparker(a)fastmail.com> wrote:
* Raphaël Mouneyres <rmouneyres(a)gmail.com>
[2016-02-28 13:18]:
Hello,
Having some bare keyboards and raspberry-sortof boards, I'd be
interested in
connecting both of them without using a midi interface, but
only the available GPIO pins available on the board. This is as well to
save external components and as a programming exercise.
After searching for information, nothing revelant was found, except a
experimental
python script to read gpio and using the mididings library to
output messages.
Is there a existing project which would scan rows/colums of a keyboard
from the
designated(configured) gpios, and throw midi message to an alsa
midi port ?
Pure Data
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-user
2:45 p.m.
Am 28.02.2016 um 13:18 schrieb Raphaël Mouneyres:
Is there a existing project which would scan
rows/colums of a keyboard from the designated(configured) gpios, and throw midi message to
an alsa midi port ?
Such a software would have to vary according to the keyboard model, the
available GPIO ports and the extra electronic components used (e.g.
shift registers or de-multiplexers).
A general purpose operating system like Linux is not best suited for
such an application, since the scanning rate should be in the
sub-millisecond range to get a good velocity resolution (assuming you
have a keyboard with two contacts per key).
A project that generally does what you want is midibox. It's an OS for
electronic musical devices, which runs on STM32F4 discovery boards (ARM
Cortex M4 processor) and has keyboard matrix scanning facilities build
in. You can attach DIN MIDI in- and outputs or use it as a USB-MIDI
client via the micro-USB connector of the discovery board or even have
it send OSC via ethernet.
http://ucapps.de/midibox_ng.html
http://ucapps.de/mbhp_core_stm32f4.html
http://ucapps.de/mbhp_dio_matrix.html
Chris
7:27 p.m.
Such a software would have to vary according to the
keyboard model, the
available GPIO ports and the extra electronic components used (e.g.
shift registers or de-multiplexers).
Most keyboards are arranged in a matrix fashion so they have about 16 wires for a 64 notes
keyboard.
this may already bee too much for a raspberry, so using a multiplexer is probably
mandatory.
A general purpose operating system like Linux is not
best suited for
such an application, since the scanning rate should be in the
sub-millisecond range to get a good velocity resolution (assuming you
have a keyboard with two contacts per key).
A project that generally does what you want is midibox.
Yes, i have built several midiboxes and also arduino alikes, so very familiar with this
easy and efficient way to do midi thing.
I mentioned I would like to avoid extra boards and use ressources existing on the cpu
board.
A few multiplexer chips are still easier/cheaper than any midiboard.
As you say, the sub-millisecond timing for the keyboard scanning is important, so if it is
not doable in-the-box, even with some real-time kernel and associated module, i would
certainly go with those solutions.
Raphaël
7:53 p.m.
On Sun, 28 Feb 2016 20:27:34 +0100
Raphaël Mouneyres <rmouneyres(a)gmail.com> wrote:
What speed does a standard USB keyboard encoder work at?
Can it's clock be sped up without upsetting the USBlink?
Although speed wasn't an issue for me, I once used an old keyboard for this (had
intermittent key contacts) and just wired a discrete switch matrix onto it, for
dedicated functions.
--
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.
Such a
software would have to vary according to the keyboard model, the
available GPIO ports and the extra electronic components used (e.g.
shift registers or de-multiplexers).
Most keyboards are arranged in a matrix fashion so they have about 16 wires for a 64
notes keyboard.
this may already bee too much for a raspberry, so using a multiplexer is probably
mandatory.
A general purpose operating system like Linux is
not best suited for
such an application, since the scanning rate should be in the
sub-millisecond range to get a good velocity resolution (assuming you
have a keyboard with two contacts per key).
A project that generally does what you want is midibox.
Yes, i have built several midiboxes and also arduino alikes, so very familiar with this
easy and efficient way to do midi thing.
I mentioned I would like to avoid extra boards and use ressources existing on the cpu
board.
A few multiplexer chips are still easier/cheaper than any midiboard.
As you say, the sub-millisecond timing for the keyboard scanning is important, so if it
is not doable in-the-box, even with some real-time kernel and associated module, i would
certainly go with those solutions.
Raphaël 
11:01 p.m.
On Sun, 28 Feb 2016, Will Godfrey wrote:
What speed does a standard USB keyboard encoder work
at?
Can it's clock be sped up without upsetting the USBlink?
From what I can tell from having taken several mice and
keyboards apart...
they are really ps2 (seems not USB anyway) inside and the USB
plug shell
contains a ps2 serial to USB circuit. This is why the cables from the kb
to the connector are so skinny and not shielded. Also USB limits chording
to 6, but ps2 can have more (if designed that way). In practice 6 key
chording would be ok for most things I do... but I am not a good keyboard
player.
The ps2 wiki page:
https://en.wikipedia.org/wiki/PS/2_port
Seems to indicate that USB has higher latency, enough that some gamers
prefer ps2.
I have kept getting MB with ps2 mouse ports because at one time I noticed
that mouse movement seemed to acompany xruns with USB mice... I have
absolutely not tested this on any modern MB and I do not have a USB AI so
my USB interrupts are not prioritized anyway.
--
Len Ovens
www.ovenwerks.net
7:26 p.m.
On Sun, 28 Feb 2016, Raphaël Mouneyres wrote:
Having some bare keyboards and raspberry-sortof
boards, I'd be
interested in connecting both of them without using a midi interface,
but only the available GPIO pins available on the board. This is as well
to save external components and as a programming exercise.
Sort of in the same boat... I have a RPi on order and wish to use it as
the core of a MIDI/OSC/possibly OCA controller. I am using as a control
surface with buttons and encoders in the form of a mixer.
I want it to be cheap as in cost only a little and am finding it less
expensive to buy things than parts. For example, I want displays for
mettering, for encoder values, for switch value. look up encoder rings,
look up the supporting circuitry... not cheap, so I thought I can get a
7inch touch screen to put all that on that will plug right into the Rpi
pretty much $100CAD, but I was able to get a new android 9 inch tablet for
$70CAD which can act as a network teather device over USB. As a bonus, the
same sw I will have to develop to use it, will allow it to be used
wirelessly too.
Switches are also not cheap. even membrane switches end up costing more
than $1 each. I find this mind blowing when I paid $3 at the dollar store
for a keyboard with over 100 switches that comes with a controller built
in. Out of which I built this:
http://www.ovenwerks.net/hardware/3dollarcontrolsurface.html
The SW is user space and talks to Jack MIDI rather than ALSA.. I'll talk
more about that below.
I don't like membrane switches. However I can get a keyboard with cherry
mechanical switches for under $100 with no ledgend on them. (quite a lot
less for Cherry black, not so much less for Cherry Brown) Some of them
even have a LED per key (but not so much an individual method of driving
them I think)
I was originally planning to take my $3 keyboard and cut it up into 4
switch rows and rewire it, and plug the USB into into my RPi... done, I
have the SW to compile on the rpi already to go :) The "rollover" is only
4 and it would probably be nice to have more, but a lot of the mechanical
KB have "n rollover" if they are used with PS2. So I am going to see if I
can set up one of the RPi serial lines to deal with that.
After searching for information, nothing revelant was
found, except a
experimental python script to read gpio and using the mididings library
to output messages.
What kind of a keyboard for what use? If you mean a piano style keyboard
then latency becomes more important. I would suggest script may not be the
best way to go. c or c++ makes more sense.
Is there a existing project which would scan
rows/colums of a keyboard
from the designated(configured) gpios, and throw midi message to an alsa
midi port ?
My next phase for midikb (the SW I used above) is to add ALSA MIDI to the
mix. However, have you looked at:
http://ucapps.de/
http://wiki.midibox.org/
They do not use the RPi mostly because this project has been around longer
than the RPi.
Would such a program better be a kernel module or a
userland program ?
Personally I would like to get my project out of userland. Right now I am
using Jack so user land it is. But that means I have to give the user
access to the /dev/input/* files which are normally system. This does lend
itself to a possible security problem. (though the same thing may be
possible at the user level in X or whatever session manager is used. So I
would like to move to ALSA because it seems ALSA midi can deal with midi
ports across users (someone correct me if I am wrong). It looks (so far)
easier to run a system service tha "grabs" a keyboard (or the output of a
keyboard scanner) and just outputs MIDI to the ALSA sequencer ports. It is
still possible to tell ALSA "this is a HW device" from there. So that is
the next step in my audio SW training :) Making a kernel module/patch is
at another level of programming which i may attempt some day by starting
with the snd-serial-u16550 or mpu401 code.
In your case you need to learn about the scanning part first. This is
pretty much straight bit bang stuff. If you happen to have a set of
address lines, set to 0x01 output. then input data or input bit at a time.
Then shift left and input again. Not hard. Placement of diodes on switches
is important to allow chording (more than one switch at a time). After you
have this input you will want to do some debounce. Then you have a list of
keys that are down. What you do with them from there is up to you, some
kind of a lookup table to convert from key to MIDI note... 8 address by 8
data lines will give you 64 keys. Thats 16 GPIO lines for no external
circuitry. The RPi is not overflowing with gpio that are not
multipurpose... so maybe try this:
http://pi.gadgetoid.com/article/building-the-pico-piduino
or this:
http://www.hardkernel.com/main/products/prdt_info.php?g_code=G135390529643
Not very comprehensive for sure. However, that is what DIY is all about,
Take the bits, do research, make something new.
Enjoy.
--
Len Ovens
www.ovenwerks.net
7:48 p.m.
I was originally planning to take my $3 keyboard and
cut it up into 4 switch rows and rewire it, and plug the USB into into my RPi... done, I
have the SW to compile on the rpi already to go :) The "rollover" is only 4 and
it would probably be nice to have more, but a lot of the mechanical KB have "n
rollover" if they are used with PS2. So I am going to see if I can set up one of the
RPi serial lines to deal with that.
hello Len, I had deep^ly looked at you excellent work with this keyboard midi controller
when you mentioned it on the list. Excellent work !
After searching for information, nothing revelant
was found, except a experimental python script to read gpio and using the mididings
library to output messages.
What kind of a keyboard for what use? If you mean a piano style keyboard then latency
becomes more important. I would suggest script may not be the best way to go. c or c++
makes more sense. Is there a existing project which would scan
rows/colums of a keyboard from the designated(configured) gpios, and throw midi message to
an alsa midi port ?
My next phase for midikb (the SW I used above) is to add ALSA MIDI to the mix. However,
have you looked at:
http://ucapps.de/
http://wiki.midibox.org/
They do not use the RPi mostly because this project has been around longer than the RPi.
Would such a program better be a kernel module or
a userland program ?
Making a kernel module/patch is at another level of programming which i may attempt some
day by starting with the snd-serial-u16550 or mpu401 code. Placement of diodes on switches is important to allow
chording (more than one switch at a time).
The keyboards I have (from unrepaired pianos/organs) have all the diode matrix in place.
Ready to use.
After you have this input you will want to do some
debounce. Then you have a list of keys that are down. What you do with them from there is
up to you, some kind of a lookup table to convert from key to MIDI note... 8 address by 8
data lines will give you 64 keys. Thats 16 GPIO lines for no external circuitry. The RPi
is not overflowing with gpio that are not multipurpose... so maybe try this:
http://pi.gadgetoid.com/article/building-the-pico-piduino
this is only a lightweight arduino way to do the thing, I would not learn anything new
using this µp, and I love to learn new things.
Would it be that nobody tried it before because it is so easy to do with an external µp ?
would better use multiplexers on the GPIOs
Not very comprehensive for sure. However, that is what DIY is all about, Take the bits,
do research, make something new.
indeed, your answers are part of the quest.
Raphaël
2985
days inactive
2985
days old
linux-audio-user@lists.linuxaudio.org
9 comments
6 participants
participants (6)
-
Christopher Arndt -
Ivica Bukvic -
Len Ovens -
Peter P. -
Raphaël Mouneyres -
Will Godfrey