Hi all,
I'm a little confused by the behaviour of the [key] and [keyup] objects. What I'd expect is that they 'bang' and output the number only and only when a key is pressed (key) or depressed (keyup), while it looks like while a key is kept pressed they go on banging. Also a [keyup] seems to bang even when a key is 'down'. This also poses somewhat a problem with keyboard 'poliphony' say I keep a key pressed while also pressing other[s].
Is my expectation simply wrong? I noticed that the behaviour is different when pressing keys like SHIFT, CTRL etc. Also I see from the help this is system dependent, I see this on Linux (ubuntu 9,04 - Pd 0.41.4-extended-rc1)
Thanks, Lorenzo
Lorenzo wrote:
Hi all,
I'm a little confused by the behaviour of the [key] and [keyup] objects. What I'd expect is that they 'bang' and output the number only and only when a key is pressed (key) or depressed (keyup), while it looks like while a key is kept pressed they go on banging. Also a [keyup] seems to bang even when a key is 'down'. This also poses somewhat a problem with keyboard 'poliphony' say I keep a key pressed while also pressing other[s].
Is my expectation simply wrong? I noticed that the behaviour is different when pressing keys like SHIFT, CTRL etc.
that behaviour comes from the OS, those objects listen to the events that are sent to pd from the X server, not to the raw USB events that [hidio] uses. To fix your problem you have change the key repeat preferences on whatever OS you are using. You may also find you have issues with which window is in focus - to receive the events the appropriate pd window must be in focus. Again [hidio] [hid] etc use the keyboard more directly, and receive all events even if the keyboard in question is not being used by X, in addition you may select individual devices with [hidio] while it is the sum of all the attached keyboards, plus any synthetic X events, that [key] and [keyup] use.
But yes, [hidio] works for me with Debian and OSX, but it does not work with Windows, apparently the USB interface is a pain, and quite difficult to work with.
Simon
Dear Simon,
Thanks for your explanation. Indeed the objects are simply behaving as if one were typing (say in a text editor, console etc.). Right now I'm on Windows and the behaviour is exactly the same as the Ubuntu machine. In fact it looked so trivial I had overlooked it (I admit I was a little biased by previous experience with the homonym objects in MAX).
I guess a similar scenario (many possible keys together) is games where the user may be pressing more keys at once (say a 'fire' key kept down while 'moving' keys etc.).
Kind regards, Lorenzo.
Quoth Lorenzo, on 12/07/09 14:46:
Hi all,
I'm a little confused by the behaviour of the [key] and [keyup] objects. What I'd expect is that they 'bang' and output the number only and only when a key is pressed (key) or depressed (keyup), while it looks like while a key is kept pressed they go on banging. Also a [keyup] seems to bang even when a key is 'down'. This also poses somewhat a problem with keyboard 'poliphony' say I keep a key pressed while also pressing other[s].
Is my expectation simply wrong? I noticed that the behaviour is different when pressing keys like SHIFT, CTRL etc. Also I see from the help this is system dependent, I see this on Linux (ubuntu 9,04 - Pd 0.41.4-extended-rc1)
Thanks, Lorenzo
Hi Lorenzo,
[key] and [keyup] are dependant on keyboard settings in your OS. In Ubuntu 9.04 you can turn off Repeat Keys under System/Preferences/Keyboard. In windows I think you can slow the key repeat rate down, but not disable it completely. I don't know about Mac OS.
James
that behaviour comes from the OS, those objects listen to the events that are sent to pd from the X server, not to the raw USB events that [hidio] uses. To fix your problem you have change the key repeat preferences on whatever OS you are using. You may also find you have issues with which window is in focus - to receive the events the appropriate pd window must be in focus.
It took me a little while to work this out, so I'll share this in case anyone is looking at similar problems, and wants to control exactly what inputs are used by X and when, so they can use keyboards, mice, tablets etc as controls in pd without also controlling the pointer etc ...
A month or two ago Debian Sid moved to the new version of Xorg [some of the other distributions moved over earlier] and this has meant huge changes to the way input devices are dealt with, and now HAL is the primary way that X gets info about accessing devices. It is now possible to have a nearly empty xorg.conf, or even no xorg.conf at all. It is also possible to stick with the old style of configuration if you wish, but you will have to add a couple of extra lines to your old xorg.conf if this is what you want.
This article is well worth reading to find out more:
http://wiki.debian.org/XStrikeForce/InputHotplugGuide
It seems that the HAL way of doing things, using it's configuration files, is a lot more flexible and much more hot-pluggable than the old way, but uses a completely different set of configuration files.
I have been wondering how hard it would be to make [hidio] into something that works through HAL, maybe called [halio], to be able to access many devices that register with HAL instead of just USB devices, but to stick with a very similar interface to [hidio], and preferably stay compatible for usb-hid devices?? It would of course be Linux only because HAL is a purely Linux way of doing things.
That would be a very long-term learning exercise for me, with no results for some time, if at all - but the results would be great!
Some other commands you may want to look at for more tricks, all extremely easy to set up in Debian, then usable in pd with a few scripts and [shell] (or maybe use pdreceive in a pipe?) are the ones that create X events - so that you can create mouse and keyboard events, moving the windows of other apps around and sending keystrokes, mouse events, text selections and more - try out these packages ...
xdotool xautomation xsel
plus these utilities from x11-utils to help: xev xwininfo xprop
Simon
-
James Dunn -
Lorenzo -
Simon Wise