Many thanks for the explanation! What seems weird, however, is how divergent time delta between repeats is. On Windows it is always around 30ms (at least on my hardware) whereas on Linux it goes between 0, including 1.4ms and up to 50+. Even when accounting for jitter between two events I cannot imagine that they oscillate that much (unless my flavor of kernel/hardware treats keypress timing like a dirt :-).
Best wishes,
Ico
martin.peach@sympatico.ca wrote:
It probably happens when you get two keydowns in the space of one Pd event loop. The second is output at the same time. The same thing happens with [metro] banging serial data into [comport] or [midiout]. The metro rate is quantized to the event loop rate, so individual bangs are irregularly spaced but the mean time over many bangs is perfect. The only way to get perfect timing is to use signals, messages are always handled after the sound has been computed. So if you don't like it you could slow down your keyboard repeat rate to slower than Pd, or use a microphone to detect the keypresses ;)
Martin
Ico wrote:
It all started when I noticed that my threaded version of coll object tended to freeze Pd at apparently random points. As it turns out, I was testing its robustness simply by passing a key into a read/write message and holding the key down to generate a large number of requests per second and the [key] object at times seemed to spit out (while autorepeat of the pressed key was taking place) two outputs at the same time which in turn crashed Pd as threaded coll object did not handle this gracefully. I've since fixed the coll object but the key behavior baffles me.
The double redundant output is apparent in both rt and non-rt Pd (on Ubuntu 9.10 using rt kernel on the MSI Wind atom netbook) and below is the simplest patch to invoke this.
Basically, I am measuring the aforesaid time delta between broadcast strokes using timer object and printing it out to console.
#N canvas 549 345 383 297 10; #X obj 162 83 key; #X obj 162 107 sel 32; #X text 208 108 space; #X obj 162 145 timer; #X obj 162 182 print; #X connect 0 0 1 0; #X connect 1 0 3 1; #X connect 1 0 3 0; #X connect 3 0 4 0;
So, while certainly the fact that threaded version of coll wasn't handling gracefully multiple redundant requests at the same time was a bug (which I am hoping has been fixed now), I am wondering whether the aforesaid [key] behavior might be a bug as it seems to me that keystrokes of the same key, even if the key is autorepeating should never have a time delta of zero. Naturally, one can always put a speedlim after the [key] object but that might result in a truncated output of fast typing.
I would greatly appreciate it if others can test this to see if they are getting the same results.
FWIW, allowing this kind of key behavior in more complex patches did result in the pd<->gui communication tearing with the stderr reporting several truncated messages before crashing. Due to their complexity and unpredictability of a point where tearing would occur I am not sure where the problem might be stemming from but it is undoubtedly at least in part instigated by double redundant output from the key object possibly in conjunction with objects that may have not provided graceful handling of such requests.
NB: I only tested the same patch on Win platform and there it does not exhibit this problem.
Any thoughts would be most appreciated.
Best wishes,
Ico
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
I got curious, so I did this little test with auto-repeated keys: [image: keytimetest.jpg]
strange indeed :) gr, Tim
2010/9/27 Ivica Ico Bukvic ico@vt.edu
Many thanks for the explanation! What seems weird, however, is how divergent time delta between repeats is. On Windows it is always around 30ms (at least on my hardware) whereas on Linux it goes between 0, including 1.4ms and up to 50+. Even when accounting for jitter between two events I cannot imagine that they oscillate that much (unless my flavor of kernel/hardware treats keypress timing like a dirt :-).
Best wishes,
Ico
martin.peach@sympatico.ca wrote:
It probably happens when you get two keydowns in the space of one Pd event
loop. The second is output at the same time. The same thing happens with [metro] banging serial data into [comport] or [midiout]. The metro rate is quantized to the event loop rate, so individual bangs are irregularly spaced but the mean time over many bangs is perfect. The only way to get perfect timing is to use signals, messages are always handled after the sound has been computed.
So if you don't like it you could slow down your keyboard repeat rate to
slower than Pd, or use a microphone to detect the keypresses ;)
Martin
Ico wrote:
It all started when I noticed that my threaded version of coll object tended to freeze Pd at apparently random points. As it turns out, I was testing its robustness simply by passing a key into a read/write message and holding the key down to generate a large number of requests per second and the [key] object at times seemed to spit out (while autorepeat of the pressed key was taking place) two outputs at the same time which in turn crashed Pd as threaded coll object did not handle this gracefully. I've since fixed the coll object but the key behavior baffles me.
The double redundant output is apparent in both rt and non-rt Pd (on Ubuntu 9.10 using rt kernel on the MSI Wind atom netbook) and below is the simplest patch to invoke this.
Basically, I am measuring the aforesaid time delta between broadcast strokes using timer object and printing it out to console.
#N canvas 549 345 383 297 10; #X obj 162 83 key; #X obj 162 107 sel 32; #X text 208 108 space; #X obj 162 145 timer; #X obj 162 182 print; #X connect 0 0 1 0; #X connect 1 0 3 1; #X connect 1 0 3 0; #X connect 3 0 4 0;
So, while certainly the fact that threaded version of coll wasn't handling gracefully multiple redundant requests at the same time was a bug (which I am hoping has been fixed now), I am wondering whether the aforesaid [key] behavior might be a bug as it seems to me that keystrokes of the same key, even if the key is autorepeating should never have a time delta of zero. Naturally, one can always put a speedlim after the [key] object but that might result in a truncated output of fast typing.
I would greatly appreciate it if others can test this to see if they are getting the same results.
FWIW, allowing this kind of key behavior in more complex patches did result in the pd<->gui communication tearing with the stderr reporting several truncated messages before crashing. Due to their complexity and unpredictability of a point where tearing would occur I am not sure where the problem might be stemming from but it is undoubtedly at least in part instigated by double redundant output from the key object possibly in conjunction with objects that may have not provided graceful handling of such requests.
NB: I only tested the same patch on Win platform and there it does not exhibit this problem.
Any thoughts would be most appreciated.
Best wishes,
Ico
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
What is the range of the graph? How many hits is your graph showing?
Would this perhaps warrant a small adjustment to Linux code where it checks whether the key of certain type has been outputted in this update and if so, discard repeated occurrence?
Best wishes,
Ico
From: tim vets [mailto:timvets@gmail.com] Sent: Monday, September 27, 2010 1:21 PM To: Ivica Ico Bukvic Cc: martin.peach@sympatico.ca; pd-list@iem.at; pd-dev@iem.at Subject: Re: [PD] [PD-dev] odd key object behavior under Linux
I got curious, so I did this little test with auto-repeated keys:
keytimetest.jpg
strange indeed :)
gr,
Tim
2010/9/27 Ivica Ico Bukvic ico@vt.edu
Many thanks for the explanation! What seems weird, however, is how divergent time delta between repeats is. On Windows it is always around 30ms (at least on my hardware) whereas on Linux it goes between 0, including 1.4ms and up to 50+. Even when accounting for jitter between two events I cannot imagine that they oscillate that much (unless my flavor of kernel/hardware treats keypress timing like a dirt :-).
Best wishes,
Ico
martin.peach@sympatico.ca wrote:
It probably happens when you get two keydowns in the space of one Pd event loop. The second is output at the same time. The same thing happens with [metro] banging serial data into [comport] or [midiout]. The metro rate is quantized to the event loop rate, so individual bangs are irregularly spaced but the mean time over many bangs is perfect. The only way to get perfect timing is to use signals, messages are always handled after the sound has been computed. So if you don't like it you could slow down your keyboard repeat rate to slower than Pd, or use a microphone to detect the keypresses ;)
Martin
Ico wrote:
It all started when I noticed that my threaded version of coll object tended to freeze Pd at apparently random points. As it turns out, I was testing its robustness simply by passing a key into a read/write message and holding the key down to generate a large number of requests per second and the [key] object at times seemed to spit out (while autorepeat of the pressed key was taking place) two outputs at the same time which in turn crashed Pd as threaded coll object did not handle this gracefully. I've since fixed the coll object but the key behavior baffles me.
The double redundant output is apparent in both rt and non-rt Pd (on Ubuntu 9.10 using rt kernel on the MSI Wind atom netbook) and below is the simplest patch to invoke this.
Basically, I am measuring the aforesaid time delta between broadcast strokes using timer object and printing it out to console.
#N canvas 549 345 383 297 10; #X obj 162 83 key; #X obj 162 107 sel 32; #X text 208 108 space; #X obj 162 145 timer; #X obj 162 182 print; #X connect 0 0 1 0; #X connect 1 0 3 1; #X connect 1 0 3 0; #X connect 3 0 4 0;
So, while certainly the fact that threaded version of coll wasn't handling gracefully multiple redundant requests at the same time was a bug (which I am hoping has been fixed now), I am wondering whether the aforesaid [key] behavior might be a bug as it seems to me that keystrokes of the same key, even if the key is autorepeating should never have a time delta of zero. Naturally, one can always put a speedlim after the [key] object but that might result in a truncated output of fast typing.
I would greatly appreciate it if others can test this to see if they are getting the same results.
FWIW, allowing this kind of key behavior in more complex patches did result in the pd<->gui communication tearing with the stderr reporting several truncated messages before crashing. Due to their complexity and unpredictability of a point where tearing would occur I am not sure where the problem might be stemming from but it is undoubtedly at least in part instigated by double redundant output from the key object possibly in conjunction with objects that may have not provided graceful handling of such requests.
NB: I only tested the same patch on Win platform and there it does not exhibit this problem.
Any thoughts would be most appreciated.
Best wishes,
Ico
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
2010/9/28 Ivica Ico Bukvic ico@vt.edu
What is the range of the graph? How many hits is your graph showing?
if you're talking about my graph: the actual keyboard autorepeat rate here is at about 30 ms with these mysterious regularly alternating highs and lows. The other peaks in the graph are just where I released a key for a while to choose another test key to hold down. arrow keys show a different result than, say, a letter key... (test done here on "Ubuntu 8.04 - the Hardy Heron", Pd version 0.41.4-extended) gr, Tim
Would this perhaps warrant a small adjustment to Linux code where it checks
whether the key of certain type has been outputted in this update and if so, discard repeated occurrence?
Best wishes,
Ico
*From:* tim vets [mailto:timvets@gmail.com] *Sent:* Monday, September 27, 2010 1:21 PM *To:* Ivica Ico Bukvic *Cc:* martin.peach@sympatico.ca; pd-list@iem.at; pd-dev@iem.at *Subject:* Re: [PD] [PD-dev] odd key object behavior under Linux
I got curious, so I did this little test with auto-repeated keys:
[image: keytimetest.jpg]
strange indeed :)
gr,
Tim
2010/9/27 Ivica Ico Bukvic ico@vt.edu
Many thanks for the explanation! What seems weird, however, is how divergent time delta between repeats is. On Windows it is always around 30ms (at least on my hardware) whereas on Linux it goes between 0, including 1.4ms and up to 50+. Even when accounting for jitter between two events I cannot imagine that they oscillate that much (unless my flavor of kernel/hardware treats keypress timing like a dirt :-).
Best wishes,
Ico
martin.peach@sympatico.ca wrote:
It probably happens when you get two keydowns in the space of one Pd event
loop. The second is output at the same time. The same thing happens with [metro] banging serial data into [comport] or [midiout]. The metro rate is quantized to the event loop rate, so individual bangs are irregularly spaced but the mean time over many bangs is perfect. The only way to get perfect timing is to use signals, messages are always handled after the sound has been computed.
So if you don't like it you could slow down your keyboard repeat rate to
slower than Pd, or use a microphone to detect the keypresses ;)
Martin
Ico wrote:
It all started when I noticed that my threaded version of coll object tended to freeze Pd at apparently random points. As it turns out, I was testing its robustness simply by passing a key into a read/write message and holding the key down to generate a large number of requests per second and the [key] object at times seemed to spit out (while autorepeat of the pressed key was taking place) two outputs at the same time which in turn crashed Pd as threaded coll object did not handle this gracefully. I've since fixed the coll object but the key behavior baffles me.
The double redundant output is apparent in both rt and non-rt Pd (on Ubuntu 9.10 using rt kernel on the MSI Wind atom netbook) and below is the simplest patch to invoke this.
Basically, I am measuring the aforesaid time delta between broadcast strokes using timer object and printing it out to console.
#N canvas 549 345 383 297 10; #X obj 162 83 key; #X obj 162 107 sel 32; #X text 208 108 space; #X obj 162 145 timer; #X obj 162 182 print; #X connect 0 0 1 0; #X connect 1 0 3 1; #X connect 1 0 3 0; #X connect 3 0 4 0;
So, while certainly the fact that threaded version of coll wasn't handling gracefully multiple redundant requests at the same time was a bug (which I am hoping has been fixed now), I am wondering whether the aforesaid [key] behavior might be a bug as it seems to me that keystrokes of the same key, even if the key is autorepeating should never have a time delta of zero. Naturally, one can always put a speedlim after the [key] object but that might result in a truncated output of fast typing.
I would greatly appreciate it if others can test this to see if they are getting the same results.
FWIW, allowing this kind of key behavior in more complex patches did result in the pd<->gui communication tearing with the stderr reporting several truncated messages before crashing. Due to their complexity and unpredictability of a point where tearing would occur I am not sure where the problem might be stemming from but it is undoubtedly at least in part instigated by double redundant output from the key object possibly in conjunction with objects that may have not provided graceful handling of such requests.
NB: I only tested the same patch on Win platform and there it does not exhibit this problem.
Any thoughts would be most appreciated.
Best wishes,
Ico
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
One thing that would make a lot of sense is to make the [key] object
only output keydown and keyup events, and not output the auto-
generated repeats.
.hc
On Sep 28, 2010, at 1:51 AM, tim vets wrote:
2010/9/28 Ivica Ico Bukvic ico@vt.edu What is the range of the graph? How many hits is your graph showing?
if you're talking about my graph: the actual keyboard autorepeat rate here is at about 30 ms with these mysterious regularly alternating highs and lows. The other peaks in the graph are just where I released a key for a
while to choose another test key to hold down. arrow keys show a different result than, say, a letter key... (test done here on "Ubuntu 8.04 - the Hardy Heron", Pd version
0.41.4-extended) gr, TimWould this perhaps warrant a small adjustment to Linux code where it
checks whether the key of certain type has been outputted in this
update and if so, discard repeated occurrence?Best wishes,
Ico
From: tim vets [mailto:timvets@gmail.com] Sent: Monday, September 27, 2010 1:21 PM To: Ivica Ico Bukvic Cc: martin.peach@sympatico.ca; pd-list@iem.at; pd-dev@iem.at Subject: Re: [PD] [PD-dev] odd key object behavior under Linux
I got curious, so I did this little test with auto-repeated keys:
<image001.jpg>
strange indeed :)
gr,
Tim
2010/9/27 Ivica Ico Bukvic ico@vt.edu
Many thanks for the explanation! What seems weird, however, is how
divergent time delta between repeats is. On Windows it is always
around 30ms (at least on my hardware) whereas on Linux it goes
between 0, including 1.4ms and up to 50+. Even when accounting for
jitter between two events I cannot imagine that they oscillate that
much (unless my flavor of kernel/hardware treats keypress timing
like a dirt :-).Best wishes,
Ico
martin.peach@sympatico.ca wrote:
It probably happens when you get two keydowns in the space of one
Pd event loop. The second is output at the same time. The same thing
happens with [metro] banging serial data into [comport] or
[midiout]. The metro rate is quantized to the event loop rate, so
individual bangs are irregularly spaced but the mean time over many
bangs is perfect. The only way to get perfect timing is to use
signals, messages are always handled after the sound has been
computed.So if you don't like it you could slow down your keyboard repeat
rate to slower than Pd, or use a microphone to detect the
keypresses ;)Martin
Ico wrote:
It all started when I noticed that my threaded version of coll
object
tended to freeze Pd at apparently random points. As it turns out,
I was
testing its robustness simply by passing a key into a read/write
message
and holding the key down to generate a large number of requests per second and the [key] object at times seemed to spit out (while autorepeat of the pressed key was taking place) two outputs at
the same
time which in turn crashed Pd as threaded coll object did not
handle
this gracefully. I've since fixed the coll object but the key
behavior
baffles me.
The double redundant output is apparent in both rt and non-rt Pd
(on
Ubuntu 9.10 using rt kernel on the MSI Wind atom netbook) and
below is
the simplest patch to invoke this.
Basically, I am measuring the aforesaid time delta between
broadcast
strokes using timer object and printing it out to console.
#N canvas 549 345 383 297 10; #X obj 162 83 key; #X obj 162 107 sel 32; #X text 208 108 space; #X obj 162 145 timer; #X obj 162 182 print; #X connect 0 0 1 0; #X connect 1 0 3 1; #X connect 1 0 3 0; #X connect 3 0 4 0;
So, while certainly the fact that threaded version of coll wasn't handling gracefully multiple redundant requests at the same time
was a
bug (which I am hoping has been fixed now), I am wondering
whether the
aforesaid [key] behavior might be a bug as it seems to me that keystrokes of the same key, even if the key is autorepeating should never have a time delta of zero. Naturally, one can always put a speedlim after the [key] object but that might result in a
truncated
output of fast typing.
I would greatly appreciate it if others can test this to see if
they are
getting the same results.
FWIW, allowing this kind of key behavior in more complex patches
did
result in the pd<->gui communication tearing with the stderr
reporting
several truncated messages before crashing. Due to their
complexity and
unpredictability of a point where tearing would occur I am not sure where the problem might be stemming from but it is undoubtedly at
least
in part instigated by double redundant output from the key object possibly in conjunction with objects that may have not provided
graceful
handling of such requests.
NB: I only tested the same patch on Win platform and there it
does not
exhibit this problem.
Any thoughts would be most appreciated.
Best wishes,
Ico
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
<keystroketester.pd>_______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
kill your television
Indeed. However, does Linux's API allow for this?
From: Hans-Christoph Steiner [mailto:hans@at.or.at] Sent: Sunday, October 10, 2010 6:26 PM To: tim vets Cc: Ivica Ico Bukvic; pd-list@iem.at; martin.peach@sympatico.ca; pd-dev@iem.at Subject: Re: [PD] [PD-dev] odd key object behavior under Linux
One thing that would make a lot of sense is to make the [key] object only output keydown and keyup events, and not output the auto-generated repeats.
.hc
On Sep 28, 2010, at 1:51 AM, tim vets wrote:
2010/9/28 Ivica Ico Bukvic ico@vt.edu
What is the range of the graph? How many hits is your graph showing?
if you're talking about my graph:
the actual keyboard autorepeat rate here is at about 30 ms
with these mysterious regularly alternating highs and lows.
The other peaks in the graph are just where I released a key for a while to choose another test key to hold down.
arrow keys show a different result than, say, a letter key...
(test done here on "Ubuntu 8.04 - the Hardy Heron", Pd version 0.41.4-extended)
gr,
Tim
Would this perhaps warrant a small adjustment to Linux code where it checks whether the key of certain type has been outputted in this update and if so, discard repeated occurrence?
Best wishes,
Ico
From: tim vets [mailto:timvets@gmail.com] Sent: Monday, September 27, 2010 1:21 PM To: Ivica Ico Bukvic Cc: martin.peach@sympatico.ca; pd-list@iem.at; pd-dev@iem.at Subject: Re: [PD] [PD-dev] odd key object behavior under Linux
I got curious, so I did this little test with auto-repeated keys:
<image001.jpg>
strange indeed :)
gr,
Tim
2010/9/27 Ivica Ico Bukvic ico@vt.edu
Many thanks for the explanation! What seems weird, however, is how divergent time delta between repeats is. On Windows it is always around 30ms (at least on my hardware) whereas on Linux it goes between 0, including 1.4ms and up to 50+. Even when accounting for jitter between two events I cannot imagine that they oscillate that much (unless my flavor of kernel/hardware treats keypress timing like a dirt :-).
Best wishes,
Ico
martin.peach@sympatico.ca wrote:
It probably happens when you get two keydowns in the space of one Pd event loop. The second is output at the same time. The same thing happens with [metro] banging serial data into [comport] or [midiout]. The metro rate is quantized to the event loop rate, so individual bangs are irregularly spaced but the mean time over many bangs is perfect. The only way to get perfect timing is to use signals, messages are always handled after the sound has been computed. So if you don't like it you could slow down your keyboard repeat rate to slower than Pd, or use a microphone to detect the keypresses ;)
Martin
Ico wrote:
It all started when I noticed that my threaded version of coll object tended to freeze Pd at apparently random points. As it turns out, I was testing its robustness simply by passing a key into a read/write message and holding the key down to generate a large number of requests per second and the [key] object at times seemed to spit out (while autorepeat of the pressed key was taking place) two outputs at the same time which in turn crashed Pd as threaded coll object did not handle this gracefully. I've since fixed the coll object but the key behavior baffles me.
The double redundant output is apparent in both rt and non-rt Pd (on Ubuntu 9.10 using rt kernel on the MSI Wind atom netbook) and below is the simplest patch to invoke this.
Basically, I am measuring the aforesaid time delta between broadcast strokes using timer object and printing it out to console.
#N canvas 549 345 383 297 10; #X obj 162 83 key; #X obj 162 107 sel 32; #X text 208 108 space; #X obj 162 145 timer; #X obj 162 182 print; #X connect 0 0 1 0; #X connect 1 0 3 1; #X connect 1 0 3 0; #X connect 3 0 4 0;
So, while certainly the fact that threaded version of coll wasn't handling gracefully multiple redundant requests at the same time was a bug (which I am hoping has been fixed now), I am wondering whether the aforesaid [key] behavior might be a bug as it seems to me that keystrokes of the same key, even if the key is autorepeating should never have a time delta of zero. Naturally, one can always put a speedlim after the [key] object but that might result in a truncated output of fast typing.
I would greatly appreciate it if others can test this to see if they are getting the same results.
FWIW, allowing this kind of key behavior in more complex patches did result in the pd<->gui communication tearing with the stderr reporting several truncated messages before crashing. Due to their complexity and unpredictability of a point where tearing would occur I am not sure where the problem might be stemming from but it is undoubtedly at least in part instigated by double redundant output from the key object possibly in conjunction with objects that may have not provided graceful handling of such requests.
NB: I only tested the same patch on Win platform and there it does not exhibit this problem.
Any thoughts would be most appreciated.
Best wishes,
Ico
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
<keystroketester.pd>_______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
kill your television
http://linux.die.net/man/3/xkbsetdetectableautorepeat
-Jonathan
--- On Mon, 10/11/10, Ivica Ico Bukvic ico@vt.edu wrote:
From: Ivica Ico Bukvic ico@vt.edu Subject: Re: [PD] [PD-dev] odd key object behavior under Linux To: "'Hans-Christoph Steiner'" hans@at.or.at, "'tim vets'" timvets@gmail.com Cc: pd-list@iem.at, martin.peach@sympatico.ca, pd-dev@iem.at Date: Monday, October 11, 2010, 3:17 AM
Indeed. However, does Linux’s API allow for this?
From: Hans-Christoph Steiner [mailto:hans@at.or.at]
Sent: Sunday, October 10, 2010 6:26 PM
To: tim vets
Cc: Ivica Ico Bukvic; pd-list@iem.at; martin.peach@sympatico.ca; pd-dev@iem.at
Subject: Re: [PD] [PD-dev] odd key object behavior under Linux
One thing that would make a lot of sense is to make the [key] object only output keydown and keyup events, and not output the auto-generated repeats.
.hc
On Sep 28, 2010, at 1:51 AM, tim vets wrote:
2010/9/28 Ivica Ico Bukvic ico@vt.edu
What is the range of the graph? How many hits is your graph showing?
if you're talking about my graph:
the actual keyboard autorepeat rate here is at about 30 ms
with these mysterious regularly alternating highs and lows.
The other peaks in the graph are just where I released a key for a while to choose another test key to hold down.
arrow keys show a different result than, say, a letter key...
(test done here on "Ubuntu 8.04 - the Hardy Heron", Pd version 0.41.4-extended)
gr,
Tim
Would this perhaps warrant a small adjustment to Linux code where it checks whether the key of certain type has been outputted in this update and if so, discard repeated occurrence?
Best wishes,
Ico
From: tim vets [mailto:timvets@gmail.com]
Sent: Monday, September 27, 2010 1:21 PM
To: Ivica Ico Bukvic
Cc: martin.peach@sympatico.ca; pd-list@iem.at; pd-dev@iem.at
Subject: Re: [PD] [PD-dev] odd key object behavior under Linux
I got curious, so I did this little test with auto-repeated keys:
<image001.jpg>
strange indeed :)
gr,
Tim
2010/9/27 Ivica Ico Bukvic ico@vt.edu
Many thanks for the explanation! What seems weird, however, is how divergent time delta between repeats is. On Windows it is always around 30ms (at least on my hardware) whereas on Linux it goes between 0, including 1.4ms and up to 50+. Even when accounting for jitter between two events I cannot imagine that they oscillate that much (unless my flavor of kernel/hardware treats keypress timing like a dirt :-).
Best wishes,
Ico
martin.peach@sympatico.ca wrote:
It probably happens when you get two keydowns in the space of one Pd event
loop. The second is output at the same time. The same thing happens with [metro] banging serial data into [comport] or [midiout]. The metro rate is quantized to the event loop rate, so individual bangs are irregularly spaced but the mean time over many bangs is perfect. The only way to get perfect timing is to use signals, messages are always handled after the sound has been computed.
So if you don't like it you could slow down your keyboard repeat rate to
slower than Pd, or use a microphone to detect the keypresses ;)
Martin
Ico wrote:
It all started when I noticed that my threaded version of coll object
tended to freeze Pd at apparently random points. As it turns out, I
was
testing its robustness simply by passing a key into a read/write
message
and holding the key down to generate a large number of requests per
second and the [key] object at times seemed to spit out (while
autorepeat of the pressed key was taking place) two outputs at the
same
time which in turn crashed Pd as threaded coll object did not handle
this gracefully. I've since fixed the coll object but the key behavior
baffles me.
The double redundant output is apparent in both rt and non-rt Pd (on
Ubuntu 9.10 using rt kernel on the MSI Wind atom netbook) and below is
the simplest patch to invoke this.
Basically, I am measuring the aforesaid time delta between broadcast
strokes using timer object and printing it out to console.
#N canvas 549 345 383 297 10;
#X obj 162 83 key;
#X obj 162 107 sel 32;
#X text 208 108 space;
#X obj 162 145 timer;
#X obj 162 182 print;
#X connect 0 0 1 0;
#X connect 1 0 3 1;
#X connect 1 0 3 0;
#X connect 3 0 4 0;
So, while certainly the fact that threaded version of coll wasn't
handling gracefully multiple redundant requests at the same time was a
bug (which I am hoping has been fixed now), I am wondering whether the
aforesaid [key] behavior might be a bug as it seems to me that
keystrokes of the same key, even if the key is autorepeating should
never have a time delta of zero. Naturally, one can always put a
speedlim after the [key] object but that might result in a truncated
output of fast typing.
I would greatly appreciate it if others can test this to see if they
are
getting the same results.
FWIW, allowing this kind of key behavior in more complex patches did
result in the pd<->gui communication tearing with the stderr
reporting
several truncated messages before crashing. Due to their complexity
and
unpredictability of a point where tearing would occur I am not sure
where the problem might be stemming from but it is undoubtedly at
least
in part instigated by double redundant output from the key object
possibly in conjunction with objects that may have not provided
graceful
handling of such requests.
NB: I only tested the same patch on Win platform and there it does not
exhibit this problem.
Any thoughts would be most appreciated.
Best wishes,
Ico
Pd-dev mailing list
Pd-dev@iem.at
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
<keystroketester.pd>_______________________________________________
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
kill your television
-----Inline Attachment Follows-----
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Sun, 10 Oct 2010, Ivica Ico Bukvic wrote:
Indeed. However, does Linux’s API allow for this?
Without actually altering global keyboard settings, a fairly good trick is to check the timestamps of the events, and if a keydown happens after a keyup yet with the same timestamp, it's a repeat.
But the timestamp information is currently not sent from the Pd client to the Pd server.
| Mathieu Bouchard ------------------------------ Villeray, Montréal, QC
On Mon, 11 Oct 2010, Hans-Christoph Steiner wrote:
One thing that would make a lot of sense is to make the [key] object only output keydown and keyup events, and not output the auto-generated repeats.
Only as a non-default option.
But how do you do that ?
Usually, when I need non-repeat mode, I go to system preferences and check off the box. But I'd be glad to know how to avoid auto-repeat (reliably).
| Mathieu Bouchard ------------------------------ Villeray, Montréal, QC
excuse my naivete, but [change] does that, no? or perhaps you look for a solution at system level that I wouldn't know.
Jurgen
On Oct 11, 2010, at 7:50 PM, Mathieu Bouchard wrote:
On Mon, 11 Oct 2010, Hans-Christoph Steiner wrote:
One thing that would make a lot of sense is to make the [key] object only output keydown and keyup events, and not output the auto-generated repeats.
Only as a non-default option.
But how do you do that ?
Usually, when I need non-repeat mode, I go to system preferences and check off the box. But I'd be glad to know how to avoid auto-repeat (reliably).
On Mon, 11 Oct 2010, jurgen wrote:
excuse my naivete, but [change] does that, no?
We also want that multiple presses get through, but [change] doesn't do that and cannot do, because there's no way to make the distinction with the builtin [key] classes either (distinguish real presses from fake presses).
| Mathieu Bouchard ------------------------------ Villeray, Montréal, QC
On 11/10/10 19:50, Mathieu Bouchard wrote:
On Mon, 11 Oct 2010, Hans-Christoph Steiner wrote:
One thing that would make a lot of sense is to make the [key] object only output keydown and keyup events, and not output the auto-generated repeats.
Only as a non-default option.
But how do you do that ?
Usually, when I need non-repeat mode, I go to system preferences and check off the box. But I'd be glad to know how to avoid auto-repeat (reliably).
.. or use the device directly, say with [hid] ... but that doesn't get the combined events of all keyboards etc, just the key presses from one.
Simon
Yes, the OS also has its own event loop, which might be more responsible for that kind of timing, as it isn't running at a fixed rate and keyboard is probably a lower priority than mouse or network events.
Martin
Ico wrote:
Many thanks for the explanation! What seems weird, however, is how divergent time delta between repeats is. On Windows it is always around 30ms (at least on my hardware) whereas on Linux it goes between 0, including 1.4ms and up to 50+. Even when accounting for jitter between two events I cannot imagine that they oscillate that much (unless my flavor of kernel/hardware treats keypress timing like a dirt :-).
Best wishes,
Ico
martin.peach@sympatico.ca wrote:
It probably happens when you get two keydowns in the space of one Pd event loop. The second is output at the same time. The same thing happens with [metro] banging serial data into [comport] or [midiout]. The metro rate is quantized to the event loop rate, so individual bangs are irregularly spaced but the mean time over many bangs is perfect. The only way to get perfect timing is to use signals, messages are always handled after the sound has been computed. So if you don't like it you could slow down your keyboard repeat rate to slower than Pd, or use a microphone to detect the keypresses ;)
Martin
Ico wrote:
It all started when I noticed that my threaded version of coll object tended to freeze Pd at apparently random points. As it turns out, I was testing its robustness simply by passing a key into a read/write message and holding the key down to generate a large number of requests per second and the [key] object at times seemed to spit out (while autorepeat of the pressed key was taking place) two outputs at the same time which in turn crashed Pd as threaded coll object did not handle this gracefully. I've since fixed the coll object but the key behavior baffles me.
The double redundant output is apparent in both rt and non-rt Pd (on Ubuntu 9.10 using rt kernel on the MSI Wind atom netbook) and below is the simplest patch to invoke this.
Basically, I am measuring the aforesaid time delta between broadcast strokes using timer object and printing it out to console.
#N canvas 549 345 383 297 10; #X obj 162 83 key; #X obj 162 107 sel 32; #X text 208 108 space; #X obj 162 145 timer; #X obj 162 182 print; #X connect 0 0 1 0; #X connect 1 0 3 1; #X connect 1 0 3 0; #X connect 3 0 4 0;
So, while certainly the fact that threaded version of coll wasn't handling gracefully multiple redundant requests at the same time was a bug (which I am hoping has been fixed now), I am wondering whether the aforesaid [key] behavior might be a bug as it seems to me that keystrokes of the same key, even if the key is autorepeating should never have a time delta of zero. Naturally, one can always put a speedlim after the [key] object but that might result in a truncated output of fast typing.
I would greatly appreciate it if others can test this to see if they are getting the same results.
FWIW, allowing this kind of key behavior in more complex patches did result in the pd<->gui communication tearing with the stderr reporting several truncated messages before crashing. Due to their complexity and unpredictability of a point where tearing would occur I am not sure where the problem might be stemming from but it is undoubtedly at least in part instigated by double redundant output from the key object possibly in conjunction with objects that may have not provided graceful handling of such requests.
NB: I only tested the same patch on Win platform and there it does not exhibit this problem.
Any thoughts would be most appreciated.
Best wishes,
Ico
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-
Hans-Christoph Steiner -
Ivica Ico Bukvic -
Jonathan Wilkes -
jurgen -
martin.peach＠sympatico.ca -
Mathieu Bouchard -
Simon Wise -
tim vets