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

[Hans-Christoph Steiner]

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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20101011/b8c24375/attachment-0001.htm>