Hi all, I am being ushered to sleep so I have little time to explain this in detail, but hopefully that just means you'll all be spared tedious detail that would obfuscate the issue : ).
I'm trying to build a simple computer-key piano such as the one in Apple's GarageBand using the [key] object, and I'd like to be able to hold the keys down rather than have single shot. Key helpfully provides 0/1 notifiers for keydown and keyup - but OS X's built-in key-repeat makes it infinitely retrigger the keypress when held. The GarageBand keyboard does not do this, so I was hoping someone might have some ideas on getting around this so I don't have to pull out my (rather unportable) midi-controller when I'm patching on the road.
Thanks!
This is a known bug on all platforms, it has to do with the
implementation of the [key] object. It would be nice to have it
fixed to provide a proper key-down and key-up message instead of that
pulsing. Any volunteers?
.hc
On Jul 16, 2006, at 11:54 PM, Luke Iannini (pd) wrote:
Hi all, I am being ushered to sleep so I have little time to explain this in detail, but hopefully that just means you'll all be spared tedious detail that would obfuscate the issue : ).
I'm trying to build a simple computer-key piano such as the one in Apple's GarageBand using the [key] object, and I'd like to be able to hold the keys down rather than have single shot. Key helpfully provides 0/1 notifiers for keydown and keyup - but OS X's built-in key-repeat makes it infinitely retrigger the keypress when held. The GarageBand keyboard does not do this, so I was hoping someone might have some ideas on getting around this so I don't have to pull out my (rather unportable) midi-controller when I'm patching on the road.
Thanks!
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
I spent 33 years and four months in active military service and
during that period I spent most of my time as a high class muscle man
for Big Business, for Wall Street and the bankers. - General
Smedley Butler
Wouldn't it be straightforward to route all the expected ascii numbers to seperate [change] objects? The change can be used to prevent repeated numbers going through, so if you clear it with the keyup you can prevent the key repeats. I attached a tiny patch to show this, where the keydown code is packed with a nonzero number, and the keyup is packed with zero, so that after the route the change object sees only a 1 or 0. I'm sure somebody can come up with a nicer way to do this (with an abstraction or something)because this way requires you to manually make a [change] object for each ascii code required, plus the route needs to be edited each time a new key is required.... good luck,
Matt
-=-=-=-=-=-=-=-=-=-=-=- http://www.loopit.org -=-=-=-=-=-=-=-=-=-=-=- ----- Original Message ----- From: "Hans-Christoph Steiner" hans@eds.org To: "Luke Iannini (pd)" lukexipd@gmail.com Cc: pd-list@iem.at Sent: Monday, July 17, 2006 5:00 PM Subject: Re: [PD] Key-repeat makes keyboard-pianokeys impossible?
This is a known bug on all platforms, it has to do with the implementation of the [key] object. It would be nice to have it fixed to provide a proper key-down and key-up message instead of that pulsing. Any volunteers?
.hc
On Jul 16, 2006, at 11:54 PM, Luke Iannini (pd) wrote:
Hi all, I am being ushered to sleep so I have little time to explain this in detail, but hopefully that just means you'll all be spared tedious detail that would obfuscate the issue : ).
I'm trying to build a simple computer-key piano such as the one in Apple's GarageBand using the [key] object, and I'd like to be able to hold the keys down rather than have single shot. Key helpfully provides 0/1 notifiers for keydown and keyup - but OS X's built-in key-repeat makes it infinitely retrigger the keypress when held. The GarageBand keyboard does not do this, so I was hoping someone might have some ideas on getting around this so I don't have to pull out my (rather unportable) midi-controller when I'm patching on the road.
Thanks!
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
I spent 33 years and four months in active military service and during that period I spent most of my time as a high class muscle man for Big Business, for Wall Street and the bankers. - General Smedley Butler
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
OSX actually puts out a key release every time it repeats a key, so you still get a string of 1 0 1 0 1 0 etc.
On 7/17/06, matthew jones mj@isvr.soton.ac.uk wrote:
Wouldn't it be straightforward to route all the expected ascii numbers to seperate [change] objects? The change can be used to prevent repeated numbers going through, so if you clear it with the keyup you can prevent the key repeats. I attached a tiny patch to show this, where the keydown code is packed with a nonzero number, and the keyup is packed with zero, so that after the route the change object sees only a 1 or 0. I'm sure somebody can come up with a nicer way to do this (with an abstraction or something)because this way requires you to manually make a [change] object for each ascii code required, plus the route needs to be edited each time a new key is required.... good luck,
Matt
-=-=-=-=-=-=-=-=-=-=-=- http://www.loopit.org -=-=-=-=-=-=-=-=-=-=-=- ----- Original Message ----- From: "Hans-Christoph Steiner" hans@eds.org To: "Luke Iannini (pd)" lukexipd@gmail.com Cc: pd-list@iem.at Sent: Monday, July 17, 2006 5:00 PM Subject: Re: [PD] Key-repeat makes keyboard-pianokeys impossible?
This is a known bug on all platforms, it has to do with the implementation of the [key] object. It would be nice to have it fixed to provide a proper key-down and key-up message instead of that pulsing. Any volunteers?
.hc
On Jul 16, 2006, at 11:54 PM, Luke Iannini (pd) wrote:
Hi all, I am being ushered to sleep so I have little time to explain this in detail, but hopefully that just means you'll all be spared tedious detail that would obfuscate the issue : ).
I'm trying to build a simple computer-key piano such as the one in Apple's GarageBand using the [key] object, and I'd like to be able to hold the keys down rather than have single shot. Key helpfully provides 0/1 notifiers for keydown and keyup - but OS X's built-in key-repeat makes it infinitely retrigger the keypress when held. The GarageBand keyboard does not do this, so I was hoping someone might have some ideas on getting around this so I don't have to pull out my (rather unportable) midi-controller when I'm patching on the road.
Thanks!
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
I spent 33 years and four months in active military service and during that period I spent most of my time as a high class muscle man for Big Business, for Wall Street and the bankers. - General Smedley Butler
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
I don't see how it would be possible if, in OSX, repeated key-downs are exactly equivalent to pressing and releasing the key over and over. Maybe there could be a sort of interrupt/hold time option like with GUI bangs. If there is less than a few milliseconds between events with the same key number, they don't count. -Chuckk
"What moves men of genius, or rather what inspires their work, is not new ideas, but their obsession with the idea that what has already been said is still not enough." -Eugene Delacroix
On 7/17/06, Hans-Christoph Steiner hans@eds.org wrote:
This is a known bug on all platforms, it has to do with the implementation of the [key] object. It would be nice to have it fixed to provide a proper key-down and key-up message instead of that pulsing. Any volunteers?
.hc
On Jul 16, 2006, at 11:54 PM, Luke Iannini (pd) wrote:
Hi all, I am being ushered to sleep so I have little time to explain this in detail, but hopefully that just means you'll all be spared tedious detail that would obfuscate the issue : ).
I'm trying to build a simple computer-key piano such as the one in Apple's GarageBand using the [key] object, and I'd like to be able to hold the keys down rather than have single shot. Key helpfully provides 0/1 notifiers for keydown and keyup - but OS X's built-in key-repeat makes it infinitely retrigger the keypress when held. The GarageBand keyboard does not do this, so I was hoping someone might have some ideas on getting around this so I don't have to pull out my (rather unportable) midi-controller when I'm patching on the road.
Thanks!
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
I spent 33 years and four months in active military service and during that period I spent most of my time as a high class muscle man for Big Business, for Wall Street and the bankers. - General Smedley Butler
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
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.
and check the Tk docs for key input, maybe theres some interesting flags there..
c
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
On 7/17/06, Chuckk Hubbard badmuthahubbard@gmail.com wrote:
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.
Nevermind, that wouldn't change anything at all... my bad.
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
On Tue, 18 Jul 2006, Roman Haefeli wrote:
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.
That's what I mean about X11 timestamps. What you add to what I say, that I didn't try and didn't know, is that due to characteristics of X11, UNIX-sockets, Tk, u_main.tk, s_inter.c and a few other things, the logical delay will be 0ms almost all of the time. I can foresee that it can be non-0ms sometimes, if Pd's client and server are on different machines and/or if the X11 client and server are on different machines, due to the breaking down of events into packets; I suspect that it may also happen when just running on different CPUs, due to different process scheduling; however, I don't know how probable those glitches might be. It might only happen when transmitting 200 key/mouse events at once, for example, so maybe it's too unlikely to consider (depending on your mouse's freq).
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?
Reconfigure your keyboard... mine produces events at every 31 or 32 ms. I don't have more precise figures because I use the following Tk program:
bind all <Key> {puts %t}
where %t is a macro-variable representing time in integer milliseconds.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
Hallo, Roman Haefeli hat gesagt: // Roman Haefeli wrote:
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?
It's because of your settings. Try "xset q" to see the current settings for autorepeat, and "man xset" for how to change them. Probably Gnome has a GUI tool for that as well, but leaning xset is good, too, because you could use it in [shell]
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
hallo frank
On Tue, 2006-07-18 at 10:06 +0200, Frank Barknecht wrote:
Hallo, Roman Haefeli hat gesagt: // Roman Haefeli wrote:
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?
It's because of your settings. Try "xset q" to see the current settings for autorepeat, and "man xset" for how to change them. Probably Gnome has a GUI tool for that as well, but leaning xset is good, too, because you could use it in [shell]
Ciao
the output of 'xset q' tells me:
auto repeat delay: 500 repeat rate: 30
these values seem to have nothing to do with the 'polling frequency' or how often keyboards events are received in pd from [key]/[keyup]/[keyname]. also when i hit a [bng] with the mouse, the timer measures allways a multiple of 85.333ms, which has nothing to do with the auto-repeat setting of the keyboard, or does it? this value seems to be quite big for a program that is used in a musical context.
does anybody else measure a different value on his system and knows how to change it?
"measurement"-patch:
[bng] | [t b b] | | [timer] | [print]
cheers
roman
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Roman Haefeli wrote:
does anybody else measure a different value on his system and knows how to change it?
"measurement"-patch:
[bng] | [t b b] | | [timer] | [print]
cheers
roman
hm i use this:
[bng]
|
[ t b b b ]
¦ | ¦
¦ [bng] ¦
\ /
\ /
X
/
[realtime]
|
[print]
or do i understand something wrong?
moritz
hi mo
On Tue, 2006-07-18 at 16:04 +0200, moritz wrote:
hm i use this:
[bng] | [ t b b b ] Š | Š Š [bng] Š \ / \ / X /
[realtime] | [print]or do i understand something wrong
it is hard to read for anyone who is using a monospaced font, but i think it makes no big difference whether you use [realtime] or [timer] as long as you don't expect audio drop-outs. the difference of these two shouldn't be bigger than the message-quantization which is around 1.5ms (correct me, if i am wrong). i know that you use also ubuntu dapper with pd-0.40.0-test1. can you do the same test that frank and post the results to me?
testpatch:
[keyname] | [t b b] | | [timer] | [print]
thanks in advance
ciao
roman
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
Hallo, Roman Haefeli hat gesagt: // Roman Haefeli wrote:
does anybody else measure a different value on his system and knows how to change it?
"measurement"-patch:
[bng] | [t b b] | | [timer] | [print]
Maybe you cannot click fast enough with the mouse?
Learn how to do it from watching the legendary Takahashi Meijin: http://www.youtube.com/watch?v=A6MoEj_Hs7Y
Anyway mouse clicks don't autorepeat generally, most keyboard keys do. I get these results with "auto repeat delay: 250 repeat rate: 25" using above patch but instead of a [bng] I used the first outlet of [keyname] so I get to measure keyup and keydown events as read by Pd:
print: 249.615 print: 0 print: 40.6349 print: 0 print: 40.6349 print: 0 print: 40.6349 print: 0 print: 40.6349 print: 0 print: 40.6349 print: 0 print: 40.6349 print: 0 print: 40.6349 print: 0 print: 34.8299 print: 1.45125 print: 39.1837
According to the xset-manual: "rate is the number of repeats per second", so 25 is a value in Hz. 25 Hz correspond to a period of 40msec, so the values I get are more or less correct taken the message quantization Pd does into account.
The initial delay of 249.615 also is fine.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
hi frank
sorry to bother you again with this, but now i am getting very curious why the quantisation of x-events (from mouse or keyboard) is so big in my pd on my system and yours is so ok.
again, my 'xset q': auto repeat delay: 500 repeat rate: 30
and pd measures:
print: 512 print: 0 print: 0 print: 0 print: 0 print: 0 print: 85.3333 print: 0 print: 0 print: 0 print: 85.3333 print: 0 print: 0 print: 0 print: 0 print: 0 print: 85.3333 print: 0 print: 0 print: 0 print: 85.3333
these values are NOT ok, are they? (512 = 6 * 85.3333)
i am the only one with this problem?
On Tue, 2006-07-18 at 17:02 +0200, Frank Barknecht wrote:
Hallo, Roman Haefeli hat gesagt: // Roman Haefeli wrote:
does anybody else measure a different value on his system and knows how to change it?
"measurement"-patch:
[bng] | [t b b] | | [timer] | [print]
Maybe you cannot click fast enough with the mouse?
Learn how to do it from watching the legendary Takahashi Meijin: http://www.youtube.com/watch?v=A6MoEj_Hs7Y
:-)
yeah, i try to get this precision in pd (i don't intent to divide my
mouse into two parts though)
Anyway mouse clicks don't autorepeat generally, most keyboard keys do.
yeah, man... of course!!! i have this quantization of 85.333ms, when i hit a [bng] randomly with the mouse. the smallest time i get is also 85.333ms.
cheers roman
I get these results with "auto repeat delay: 250 repeat rate: 25" using above patch but instead of a [bng] I used the first outlet of [keyname] so I get to measure keyup and keydown events as read by Pd:
print: 249.615 print: 0 print: 40.6349 print: 0 print: 40.6349 print: 0 print: 40.6349 print: 0 print: 40.6349 print: 0 print: 40.6349 print: 0 print: 40.6349 print: 0 print: 40.6349 print: 0 print: 34.8299 print: 1.45125 print: 39.1837
According to the xset-manual: "rate is the number of repeats per second", so 25 is a value in Hz. 25 Hz correspond to a period of 40msec, so the values I get are more or less correct taken the message quantization Pd does into account.
The initial delay of 249.615 also is fine.
Ciao
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Hallo, Roman Haefeli hat gesagt: // Roman Haefeli wrote:
sorry to bother you again with this, but now i am getting very curious why the quantisation of x-events (from mouse or keyboard) is so big in my pd on my system and yours is so ok.
again, my 'xset q': auto repeat delay: 500 repeat rate: 30
and pd measures:
print: 512 print: 0 print: 0 print: 0 print: 0 print: 0 print: 85.3333 print: 0
...
these values are NOT ok, are they? (512 = 6 * 85.3333)
Hm, these values do look suspicious indeed. Unfortunatly I cannot reproduce them. Do you have any "exotic" settings in regard to blocksize or samplerate? Maybe someone else can test this as well? Test patch is attached.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
Frank Barknecht wrote:
Hallo, Roman Haefeli hat gesagt: // Roman Haefeli wrote:
sorry to bother you again with this, but now i am getting very curious why the quantisation of x-events (from mouse or keyboard) is so big in my pd on my system and yours is so ok.
again, my 'xset q': auto repeat delay: 500 repeat rate: 30
and pd measures:
print: 512 print: 0 print: 0 print: 0 print: 0 print: 0 print: 85.3333 print: 0
...
these values are NOT ok, are they? (512 = 6 * 85.3333)
The first value is the delay until the first repeat. What is your audio sample rate?
I expect that 85.3333 should be some multiple of that.
Hm, these values do look suspicious indeed. Unfortunatly I cannot reproduce them. Do you have any "exotic" settings in regard to blocksize or samplerate? Maybe someone else can test this as well? Test patch is attached.
At 44.1 kHz sample rate, 64 samples (one block) take 1.4512ms. On WinXP with (Control Panel->Keyboard->Speed = Fastest) I get:
With audio on, 5ms nominal delay: mostly 17.415 (= 12 * 1.4512) and 23.220 (= 16 * 1.4512), a jitter of exactly 4 blocks. Audio off, 5ms nominal delay, mainly: 30.4762 = 21 * 1.4512 31.9274 = 22 * 1.4512 That is, a jitter of one block. If you don't need audio this is seems to be the best jitter you can get with control-rate signals in pd.
Audio on or off, 70ms nominal delay, mainly: 29.0249 = 20 * 1.4512 34.8299 = 24 * 1.4512 Here the 4-block jitter is happening.
Setting the key repeat rate slider all the way to to Slow alternates between 412.154 and 406.349, again a jitter of exactly 4 blocks.
This is the same jitter that happens with metro and comport. In pd all 'control rate' signals are quantized to the 64-sample block, but what causes the 4-block jitter?
Martin
Ciao
#N canvas 0 0 450 300 10; #X obj 124 117 keyname; #X obj 124 144 t b b; #X obj 124 172 timer; #X obj 124 196 print; #X connect 0 0 1 0; #X connect 1 0 2 0; #X connect 1 1 2 1; #X connect 2 0 3 0;
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
hi frank, hi martin
just to finally close this topic from my side (very late, i was away for some days):
this issue with quantized key-events seems to be related with jack. the list from my last mail was done, when pd was connected to jack, and jack connected to my internals soundcard. now when i start jack on my hdsp-card, i get these values from pd:
print: 505.034 print: 2.90249 print: 26.1224 print: 2.90249 print: 31.9274 print: 2.90249 print: 37.7324 print: 2.90249 print: 31.9274 print: 2.90249 print: 31.9274 print: 2.90249 print: 31.9274 print: 2.90249
(which looks much more ok) i still don't have a clue about the underlying reason. i just can say that this is not the only problem i notice when jack runs on my internal soundcard (for some reason it always switches to a sr of 48000, no matter what i specify in the commandline or qjackctl)
ciao
roman
On Tue, 2006-07-18 at 18:36 -0400, Martin Peach wrote:
Frank Barknecht wrote:
Hallo, Roman Haefeli hat gesagt: // Roman Haefeli wrote:
sorry to bother you again with this, but now i am getting very curious why the quantisation of x-events (from mouse or keyboard) is so big in my pd on my system and yours is so ok.
again, my 'xset q': auto repeat delay: 500 repeat rate: 30
and pd measures:
print: 512 print: 0 print: 0 print: 0 print: 0 print: 0 print: 85.3333 print: 0
...
these values are NOT ok, are they? (512 = 6 * 85.3333)
The first value is the delay until the first repeat. What is your audio sample rate?
I expect that 85.3333 should be some multiple of that.
Hm, these values do look suspicious indeed. Unfortunatly I cannot reproduce them. Do you have any "exotic" settings in regard to blocksize or samplerate? Maybe someone else can test this as well? Test patch is attached.
At 44.1 kHz sample rate, 64 samples (one block) take 1.4512ms. On WinXP with (Control Panel->Keyboard->Speed = Fastest) I get:
With audio on, 5ms nominal delay: mostly 17.415 (= 12 * 1.4512) and 23.220 (= 16 * 1.4512), a jitter of exactly 4 blocks. Audio off, 5ms nominal delay, mainly: 30.4762 = 21 * 1.4512 31.9274 = 22 * 1.4512 That is, a jitter of one block. If you don't need audio this is seems to be the best jitter you can get with control-rate signals in pd.
Audio on or off, 70ms nominal delay, mainly: 29.0249 = 20 * 1.4512 34.8299 = 24 * 1.4512 Here the 4-block jitter is happening.
Setting the key repeat rate slider all the way to to Slow alternates between 412.154 and 406.349, again a jitter of exactly 4 blocks.
This is the same jitter that happens with metro and comport. In pd all 'control rate' signals are quantized to the 64-sample block, but what causes the 4-block jitter?
Martin
Ciao
#N canvas 0 0 450 300 10; #X obj 124 117 keyname; #X obj 124 144 t b b; #X obj 124 172 timer; #X obj 124 196 print; #X connect 0 0 1 0; #X connect 1 0 2 0; #X connect 1 1 2 1; #X connect 2 0 3 0;
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
You need to get the lower level events, the key-down and key-up
events from the System, not just the character stream. Its very
doable on all platforms.
.hc
On Jul 17, 2006, at 1:15 PM, Chuckk Hubbard wrote:
I don't see how it would be possible if, in OSX, repeated key-downs are exactly equivalent to pressing and releasing the key over and over. Maybe there could be a sort of interrupt/hold time option like with GUI bangs. If there is less than a few milliseconds between events with the same key number, they don't count. -Chuckk
"What moves men of genius, or rather what inspires their work, is not new ideas, but their obsession with the idea that what has already been said is still not enough." -Eugene Delacroix
On 7/17/06, Hans-Christoph Steiner hans@eds.org wrote:
This is a known bug on all platforms, it has to do with the implementation of the [key] object. It would be nice to have it fixed to provide a proper key-down and key-up message instead of that pulsing. Any volunteers?
.hc
On Jul 16, 2006, at 11:54 PM, Luke Iannini (pd) wrote:
Hi all, I am being ushered to sleep so I have little time to explain
this in
detail, but hopefully that just means you'll all be spared tedious detail that would obfuscate the issue : ).
I'm trying to build a simple computer-key piano such as the one in Apple's GarageBand using the [key] object, and I'd like to be
able to
hold the keys down rather than have single shot. Key helpfully provides 0/1 notifiers for keydown and keyup - but OS X's built-in key-repeat makes it infinitely retrigger the keypress when
held. The
GarageBand keyboard does not do this, so I was hoping someone might have some ideas on getting around this so I don't have to pull
out my
(rather unportable) midi-controller when I'm patching on the road.
Thanks!
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
I spent 33 years and four months in active military service and during that period I spent most of my time as a high class muscle man for Big Business, for Wall Street and the bankers. - General Smedley Butler
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
-- "Far and away the best prize that life has to offer is the chance to work hard at work worth doing." -Theodore Roosevelt
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
There is no way to peace, peace is the way. -A.J. Muste
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
This is a known bug on all platforms, it has to do with the
implementation of the [key] object. It would be nice to have it
fixed to provide a proper key-down and key-up message instead of that
pulsing.
I don't see that it's a bug in the [key] object. The operating systems I know all provide autorepeating keys: If you press and hold a key, it will start to generate keyup/keydown messages after a while with a certain frequency. On X11 this can be changed with the "xset" command.
Now what Garageband probably does is disable this key-repeat if Garageband has the focus, and enables it again, if the focus is lost or if an entry field gets the focus.
However this won't work in Pd: We cannot disable autorepeat everytime Pd has the focus, because that would make editing uncomfortable to say the least and for some applications autorepeat is useful outside of edit mode as well. So it's not something, [key] could fix. The solution is to leave it up to the user to take care of his/her autorepeat settings for example with "xset" (and [shell]).
An external to change autorepeat settings from inside Pd would be nice, tough.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
On 7/17/06, Frank Barknecht fbar@footils.org wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
This is a known bug on all platforms, it has to do with the implementation of the [key] object. It would be nice to have it fixed to provide a proper key-down and key-up message instead of that pulsing.
I don't see that it's a bug in the [key] object. The operating systems I know all provide autorepeating keys: If you press and hold a key, it will start to generate keyup/keydown messages after a while with a certain frequency. On X11 this can be changed with the "xset" command.
Now what Garageband probably does is disable this key-repeat if Garageband has the focus, and enables it again, if the focus is lost or if an entry field gets the focus.
However this won't work in Pd: We cannot disable autorepeat everytime Pd has the focus, because that would make editing uncomfortable to say the least and for some applications autorepeat is useful outside of edit mode as well. So it's not something, [key] could fix. The solution is to leave it up to the user to take care of his/her autorepeat settings for example with "xset" (and [shell]).
An external to change autorepeat settings from inside Pd would be nice, tough.
I think that or manually changing settings would be the only way. I just did a little timer test, and the default settings on OSX are set up so that the first keyup when autorepeating comes about 525 ms after the keydown. So to filter that would require ignoring events from the same key within about 550 ms of each other. At 120 bpm, a quarter note would stay on indefinitely. What good is keyboard note control if you can't play Stars & Stripes Forever? It would literally be forever.
-Chuckk
On Jul 17, 2006, at 2:49 PM, Chuckk Hubbard wrote:
On 7/17/06, Frank Barknecht fbar@footils.org wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
This is a known bug on all platforms, it has to do with the implementation of the [key] object. It would be nice to have it fixed to provide a proper key-down and key-up message instead of
that
pulsing.
I don't see that it's a bug in the [key] object. The operating
systems I know all provide autorepeating keys: If you press and hold a
key, it will start to generate keyup/keydown messages after a while with a certain frequency. On X11 this can be changed with the "xset"
command.Now what Garageband probably does is disable this key-repeat if Garageband has the focus, and enables it again, if the focus is lost or if an entry field gets the focus.
However this won't work in Pd: We cannot disable autorepeat everytime Pd has the focus, because that would make editing uncomfortable to
say the least and for some applications autorepeat is useful outside of edit mode as well. So it's not something, [key] could fix. The solution is to leave it up to the user to take care of his/her autorepeat settings for example with "xset" (and [shell]).An external to change autorepeat settings from inside Pd would be nice, tough.
I think that or manually changing settings would be the only way. I just did a little timer test, and the default settings on OSX are set up so that the first keyup when autorepeating comes about 525 ms after the keydown. So to filter that would require ignoring events from the same key within about 550 ms of each other. At 120 bpm, a quarter note would stay on indefinitely. What good is keyboard note control if you can't play Stars & Stripes Forever? It would literally be forever.
I forgot to mention, you can use [hid] with keyboards and get the raw
events, i.e. key-down and key-up. That'll work on Mac OS X and GNU/
Linux.
.hc
I have the audacity to believe that peoples everywhere can have three
meals a day for their bodies, education and culture for their minds,
and dignity, equality and freedom for their spirits. - Martin
Luther King, Jr.
On Mon, 17 Jul 2006, Frank Barknecht wrote:
Now what Garageband probably does is disable this key-repeat if Garageband has the focus, and enables it again, if the focus is lost or if an entry field gets the focus.
What it can also do, if the X11 server provides reliable timestamps (it normally does), is to keep a list of "on" keys and only consider "on" events that were not immediately preceded by an "off" event with the same timestamp.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
Under System Preferences, in Keyboard/Mouse, check under Keyboard; at least on 10.4.5, if you slide the "delay before repeat" slider to off, it doesn't repeat.
On 7/16/06, Luke Iannini (pd) lukexipd@gmail.com wrote:
Hi all, I am being ushered to sleep so I have little time to explain this in detail, but hopefully that just means you'll all be spared tedious detail that would obfuscate the issue : ).
I'm trying to build a simple computer-key piano such as the one in Apple's GarageBand using the [key] object, and I'd like to be able to hold the keys down rather than have single shot. Key helpfully provides 0/1 notifiers for keydown and keyup - but OS X's built-in key-repeat makes it infinitely retrigger the keypress when held. The GarageBand keyboard does not do this, so I was hoping someone might have some ideas on getting around this so I don't have to pull out my (rather unportable) midi-controller when I'm patching on the road.
Thanks!
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
late answer, but have you looked at http://www.parasitaere-kapazitaeten.net/Pd/pdpatches/keyboard_de/ you will need all patches (testkeyb.pd shows the usage) marius. ps.: (use [change] to solve the repetition problem)
Luke Iannini (pd) schrieb:
Hi all, I am being ushered to sleep so I have little time to explain this in detail, but hopefully that just means you'll all be spared tedious detail that would obfuscate the issue : ).
I'm trying to build a simple computer-key piano such as the one in Apple's GarageBand using the [key] object, and I'd like to be able to hold the keys down rather than have single shot. Key helpfully provides 0/1 notifiers for keydown and keyup - but OS X's built-in key-repeat makes it infinitely retrigger the keypress when held. The GarageBand keyboard does not do this, so I was hoping someone might have some ideas on getting around this so I don't have to pull out my (rather unportable) midi-controller when I'm patching on the road.
Thanks!
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Thanks all for your input [bang(-[laughs]. I ended up making some AppleScripts to switch Key Repeat on and off... you'll have to go into your Universal Access prefpane and switch on "Enable access for assistive devices" before they'll work.
Edit KeyboardRepeatOn.scpt to set your preference for the delay between holding a key and the beginning of repeat - it is currently set to 4.0 in the script (0 is off, 6.0 is shortest) and will replace your current setting if you do not do so.
You can of course trigger these via Quicksilver/ScriptsMenu/etc., or do as I did and code them into your patch via [osascript ~/Library/Scripts/KeyboardRepeatOff.scpt( | [shell]
Thanks Hans for your tip on HID - I'll probably get around to rebuilding my patch around it eventually.
Luke
On 7/19/06, Marius Schebella marius.schebella@chello.at wrote:
late answer, but have you looked at http://www.parasitaere-kapazitaeten.net/Pd/pdpatches/keyboard_de/ you will need all patches (testkeyb.pd shows the usage) marius. ps.: (use [change] to solve the repetition problem)
Luke Iannini (pd) schrieb:
Hi all, I am being ushered to sleep so I have little time to explain this in detail, but hopefully that just means you'll all be spared tedious detail that would obfuscate the issue : ).
I'm trying to build a simple computer-key piano such as the one in Apple's GarageBand using the [key] object, and I'd like to be able to hold the keys down rather than have single shot. Key helpfully provides 0/1 notifiers for keydown and keyup - but OS X's built-in key-repeat makes it infinitely retrigger the keypress when held. The GarageBand keyboard does not do this, so I was hoping someone might have some ideas on getting around this so I don't have to pull out my (rather unportable) midi-controller when I'm patching on the road.
Thanks!
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-
carmen -
Chuckk Hubbard -
Frank Barknecht -
Hans-Christoph Steiner -
Luke Iannini (pd) -
Marius Schebella -
Martin Peach -
Mathieu Bouchard -
matthew jones -
moritz -
Roman Haefeli