2010/9/28 Ivica Ico Bukvic <[email protected]> > 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:[email protected]] > *Sent:* Monday, September 27, 2010 1:21 PM > *To:* Ivica Ico Bukvic > *Cc:* [email protected]; [email protected]; [email protected] > *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 <[email protected]> > > 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 > > > [email protected] 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 > >> [email protected] > >> http://lists.puredata.info/listinfo/pd-dev > > > _______________________________________________ > [email protected] mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list > > >
<<image001.jpg>>
#N canvas 607 107 383 297 10; #X obj 52 25 timer; #X obj 52 62 print; #X obj 52 -12 t b b; #X obj 52 -53 keyname; #X obj 144 89 f; #X obj 178 96 + 1; #X obj 118 30 t f b; #X obj 118 8 / 30; #X obj 118 52 - 0.5; #X obj 118 170 tabwrite keytime; #X obj 223 83 table keytime 1023; #X obj 176 113 % 1023; #X symbolatom 101 -25 10 0 0 0 - - -; #X connect 0 0 1 0; #X connect 0 0 7 0; #X connect 2 0 0 0; #X connect 2 1 0 1; #X connect 3 0 2 0; #X connect 3 1 12 0; #X connect 4 0 5 0; #X connect 4 0 9 1; #X connect 5 0 11 0; #X connect 6 0 8 0; #X connect 6 1 4 0; #X connect 7 0 6 0; #X connect 8 0 9 0; #X connect 11 0 4 1;
_______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
