If it's coming from the X, can't you switch off autorepeat in the X ? Granted, I cannot find the correct documentaiton as to how to do it at the shell level, but the XkeyboardControl structure contains a flag to set it off or on... So there must be a way... Like xset -r ?
...............
int auto_repeat_mode;/* AutoRepeatModeOff, AutoRepeatModeOn,
AutoRepeatModeDefault */
} XKeyboardControl;
Just a thought...
It does not work on the computer where I am sitting but that may be because I am logged in over the network using SSH on a PuTTy terminal from a Windows machien, so nobody can figure out who's responsible for the key repeats.
-----Original Message----- From: pd-list-bounces@iem.at [mailto:pd-list-bounces@iem.at] On Behalf Of ugur guney Sent: 29 May 2007 12:28 To: Claude Heiland-Allen Cc: pd-list Subject: Re: [PD] Behavoir of [keyup] in Linux
# Adding a delay worked well. But something is surprising. The [delay] have to be longer than 0.1 to block this oscillating behavior. I'm attaching a patch (delaykey.pd) which shows the implementation. I think X11 gives the "key pressed" message in every 40 msec's or something. So 0.1 delay is not enough to block these messages. # and I'm attaching the abstracion I was using in Windows too. (keybin.pd, keybin-help.pd) -ugur-
On 5/29/07, Claude Heiland-Allen claudiusmaximus@goto10.org wrote:
ugur guney wrote:
# When I press and hold a key, after a short time
[keyup] starts to output
the number of that key repeatedly (before releasing
it). In Windows it only
outputs the key no when a key is released.
It's just the way X11 works, as far as I understand it. I did a test with GridFlow, and the same thing happens (console log from attached patch):
Here the first number is the elapsed time since the previous event (measured in Pd logical time). It would be possible to patch up something that would discard any "keyrelease immediately-followed-by keypress for the same key" pairs that occur with an elapsed time of 0 (hint: it would use [delay 0.1] or so, maybe even [delay 0] would work). The last keyrelease would be delayed a little, but it would either be unnoticeable with [delay 0.1] or at exactly the same logical time with [delay 0]