On Sun, 28 Feb 2016 20:27:34 +0100 Raphaël Mouneyres <rmouneyres@xxxxxxxxx> wrote: > > 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 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. _______________________________________________ Linux-audio-user mailing list Linux-audio-user@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/listinfo/linux-audio-user
