[PD-dev] [PD] odd key object behavior under Linux

Mon Oct 11 04:47:50 CEST 2010

http://linux.die.net/man/3/xkbsetdetectableautorepeat

-Jonathan

--- On Mon, 10/11/10, Ivica Ico Bukvic <ico at vt.edu> wrote:

From: Ivica Ico Bukvic <ico at vt.edu>
Subject: Re: [PD] [PD-dev] odd key object behavior under Linux
To: "'Hans-Christoph Steiner'" <hans at at.or.at>, "'tim vets'" <timvets at gmail.com>
Cc: pd-list at iem.at, martin.peach at sympatico.ca, pd-dev at 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 at.or.at] 

Sent: Sunday, October 10, 2010
6:26 PM

To: tim vets

Cc: Ivica Ico Bukvic;
pd-list at iem.at; martin.peach at sympatico.ca; pd-dev at 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 at 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 at gmail.com] 

Sent: Monday, September 27, 2010
1:21 PM

To: Ivica Ico Bukvic

Cc: martin.peach at sympatico.ca;
pd-list at iem.at; pd-dev at 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 at 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 at 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 at iem.at

>> http://lists.puredata.info/listinfo/pd-dev

>

_______________________________________________

Pd-list at iem.at mailing list

UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list 

<keystroketester.pd>_______________________________________________

Pd-list at iem.at mailing list

UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list 

---------------------------------------------------------------------------- 

       kill your television 

-----Inline Attachment Follows-----

_______________________________________________
Pd-list at iem.at mailing list
UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20101010/f364226c/attachment-0001.htm>