hi all
on win (and afaik on osx): keyup-event is not repeated. that makes it very easy to check, if a certain key is pressed or not. just ignore all (following) keydown-events until the corresponding keyup-event happened.
on linux: suddenly there is a different behaviour on linux (which breaks the concept, that pd behaves the same on all os', but i assume this is not the problem of pd).when a key is pressed, keydown- and -up-events are alternating, which makes everything a bit more complicated. but there is still a possibility to track keyevents in a more usefull way than 'naked' [key] and [keyup]. let me explain this with [keyname]. its left outlet outputs a [1( when a key is pressed and a [0( when the a key is released. when now a key is pressed over a long period, it outputs alternating ones and zeros (1....01..01..01..01..01..01..01..01..01..0). the insteresting thing here is that, if a key is hold down, the logical time between the [0( and the following [1( is 0ms. this means you could just ignore all 0/1-pairs, if the time between them is 0ms. since you normally don't want to trigger the same note in 0ms time, this methode won't introduce any unwanted delays.
i don't have a an example-patch at hand right now, but if somebody is interested, i could build one.
btw: on windows i measured a grid of ca. 11ms, or in other words the time between two key-events is a multiple of 11ms. on linux (ubuntu dapper without changing any settings) i measured a grid of 85.333ms. is this because of my x-settings or is pd on linux polling events only all 85.333ms?
cheers roman
On Mon, 2006-07-17 at 14:07 -0400, Chuckk Hubbard wrote:
On 7/17/06, carmen _@whats-your.name wrote:
On Mon Jul 17, 2006 at 01:15:05PM -0400, Chuckk Hubbard wrote:
I don't see how it would be possible
oh please. defeatists never win!
you could either use [change] or an [==], comparing the current and previous key. does it really send the keyup and then the keydown again for each repeat? if so you could filter it out based on the elapsed time.
But repeating the same note is really common, and [change] or [==] alone would filter that too. And elapsed time alone wouldn't work either, since it is common to hit several notes at once. So you'd have to compare both the key number and the time from its last hit. You couldn't just ignore any one key for a certain span after it is hit, because then it would start retriggering after that duration. And there is typically a delay after the first key-down before it starts repeating, so the duration would have to be long enough not to catch the following key-up.
One dirty solution, for the time being (Luke), would be to hold down another key and then play. If you hold one key down and start pressing others, nothing repeats. Just make sure that key isn't mapped to a note, since it might be interrupted before a key-up.
and check the Tk docs for key input, maybe theres some interesting flags there..
c
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de