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 >
<<keytimetest.jpg>>
_______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
