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

[tim vets]

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:
>
> [image: keytimetest.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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20100928/2a812951/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 28241 bytes
Desc: not available
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20100928/2a812951/attachment-0001.jpeg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: keystroketester.pd
Type: text/x-puredata
Size: 621 bytes
Desc: not available
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20100928/2a812951/attachment-0001.bin>