Hi David! Thanks for your reply! I'm impressed with your credentials, too :) MIDI output, sending events to the ALSA sequencer, and from there to the softsynths... Sounds great! Do you have a code example? Hm, I'm wondering if I could do this sticking to C++ builtins... Carlo

Hi Cedric, perfect, that's exactly what I need to know! Thank you very much. Carlo

not possible without specifying which graphical user toolkit you want to use. if you don't want to use a GUI toolkit, you are talking about raw terminal keycodes, which can be done but its hard, non-portable and hacky. totally out of the question.

Hi Mike! If I ever happen to change lists I'll remember your info. ;) Carlo

On Fri, Jan 20, 2006 at 02:05:30PM +0100, Alfons Adriaensen wrote: Was it really such a thing he was asking for? Anyway. The vkeybd I know of is this: http://www.alsa-project.org/~iwai/alsa.html#vkeybd regards, - Bengan ------------------------------------------------------------- - KTHNOC/SUNET/NORDUnet | http://www.noc.kth.se/~bengan | 08-7906586 -

On Fri, 20 Jan 2006, Carlo Capocasa wrote: You have to know that keyboards cannot handle tons of keys pressed simultaneously (at least the ones I tried). This might explain that. Cédric.

On Fri, 2006-01-20 at 14:35 +0100, Carlo Capocasa wrote: first of all, the design of almost all keyboards makes arbitrary use of multiple key presses at once impossible. you can google for information on this; basically there is a sensor strip below the keys that has a number of "busses" on it. different keys share these busses, and it is physically impossible to detect one key press when another is held down. as for use ncurses, it works but provides no way to detect raw key presses, only character input. hence, there is no difference in ncurses between a user pressing the tab key or the control key and "i". you also cannot detect key press and release. ardour's "ksi" interface has code that handles raw keycodes, even on another machine (network transparent raw keycode transmission, heh). it doesn't interact well with a running instance of X Window, so you can't use it inside a terminal window, but on a text console, its perfect, if i say so myself ;) --p

On Fri, 2006-01-20 at 15:21 +0100, Carlo Capocasa wrote:

Great! Thanks for your time. Carlo

On Fri, 2006-01-20 at 18:30 +0100, Carlo Capocasa wrote: download http://ardour.org/releases/ardour-0.99.tar.bz2 the code is in the "ksi" directory. look at physical_keyboard.{cc,h} to get started.

On Fri, 2006-01-20 at 20:57 +0100, Carlo Capocasa wrote: don't be ridiculous :) this was written as a private, non-library chunk of code. why would i document that? the source is much more accurate than any docs, and google will fill in the blanks.

On Fri, Jan 20, 2006 at 02:35:47PM +0100, Carlo Capocasa wrote: Computer keyboards are not designed to handle this. If some key combinations do not work in vkeybd, they'll probably fail whatever method you use. -- FA

On Friday 20 January 2006 14:35, Carlo Capocasa wrote: You're talking about ghosting issues? (For example, if you hold A, S and Z, the keyboard will either generate a ghost X, or the X key is filtered out and won't respond, depending on how smart the keyboard MCU is.) I'm afraid there's no way to fix that, as it's the result of keyboard hardware limitations. As if that isn't bad enough, the behavior varies across models and makes of keyboards. You can "sort of" make it work well enough for games buy picking keys that don't conflict in normal use, but polyphonic musical applications? No, I think that's pretty much futile, unless you modify the keyboard. (With a very simple MCU that doesn't do any smart filtering, you might get away with adding diodes at the key switches.) You need to get a proper MIDI master keyboard. Or, if you *really* want to use a PC keyboard, replace the keyboard MCU with one of these boards they use for interfacing arcade joysticks and buttons with the keyboard port or USB. Or maybe something like this: http://www.creative.com/products/product.asp?category=8&subcategory=234… (I don't know if that one's Linux compatible, though.) Well, I don't know about TCL, but your average (garbage collected) scripting language won't exactly make things more deterministic. Then again, the keyboard input subsystem isn't designed for rock solid real time operation either. If timing is critical, you should probably stick with MIDI and use ALSA directly from C code running in your audio thread, or maybe even a high priority real time thread that timestamps events as they arrive. //David Olofson - Programmer, Composer, Open Source Advocate .------- http://olofson.net - Games, SDL examples -------. | http://zeespace.net - 2.5D rendering engine | | http://audiality.org - Music/audio engine | | http://eel.olofson.net - Real time scripting | '-- http://www.reologica.se - Rheology instrumentation --'

Hmmmmmmm... well, I think you've got me pretty much convinced there are some limitations I've got to live with using the keyboard for sound :) But I see you like to push the limits and I think that's really great! Carlo

Hello, did you look at pathtoyourkernelsource/Documentation/input/input.txt . This covers the /dev/input* devices and is something to use from plain C (and C++) without the need to use any lib (probably Linux only). Jacob On Sat, Jan 21, 2006 at 11:29:46AM +0100, Carlo Capocasa wrote:

Hi Carlo, On Sun, Jan 22, 2006 at 11:11:13AM +0100, Carlo Capocasa wrote: Maybe a look into DirectFB-0.9.24/inputdrivers/linux_input/linux_input.c might help you. Get it from www.directfb.org . I don't know whether you can use the input event handling of directfb without using framebuffer or SDL, but they already have c++ bindings and they support other input sources than /dev/input/event* , too. Jacob

No problem, thanks for taking the time! Carlo