I just cranked up an old machine and pounded some before and after.  I'm sad to 
say that I do not see much of a change; I had high hopes for this.  Please 
understand that my typing is not perfect, and keyboards might not be also.

One truly nutty idea that comes to mind: we might record sound from people's 
typing and try to pick out how many keys they actually hit.  That would not be 
perfect either,  but it could easily turn out to be more objective than my best 
guess at whether I'm in fact hitting keys and they are not showing up.  I am 
confident that Pharo loses input when under stress.  You must think that too or 
you would not be working on the problem (for which thanks).

Before trying sound beyond a basic feasibility test, we should plan what we 
would do, and decide whether or not it is something we could publish.  Some 
basic thoughts would be that we should capture keyboard events vs. simply 
edited text - that would prevent problems with the backspace confusing us, and 
should also tell us what Pharo thinks about the timing of the strikes.  The 
latter should help a lot in aligning the events with sound features; any 
latencies we uncover might give useful clues too.  I _think_ I could find the 
keypresses in an audio recording; I do some work with wavelets and would 
hopefully be able to isolate the strikes with thresholding in a suitable scale. 
 Will work for co-authorship :)

If anyone is remotely interested and has a microphone already set up, a good 
starting point would be to send me recordings of a couple of people typing, 
ideally with a really good touch typist and somebody who struggles a little.  
If it looks anything like I expect, I can hopefully entice you with a wavelet 
baed detector and then we would tackle the event capture.

Eventually I would envision the usual suspects for the Sprints gathering around 
preferably an older computer with a shiny new keyboard, but that would happen 
only when we have a fix and want to compare throughput before and after the 
fix.  I would gladly crunch the acoustic data to the best of my ability.

Note that it is preferred to get data sets of an integral power of two in 
length, which of course couples with sampling frequency (Nyquist offers some 
suggestions there of course) and duration.  Another factor on duration is to 
record long enough to see a difference.  We can work out most of that later, 
assuming there is interest and we have a fix in hand.

I'll stop now :)

Bill


-----Original Message-----
From: [email protected] 
[mailto:[email protected]] On Behalf Of Michael Rueger
Sent: Saturday, October 17, 2009 5:55 AM
To: [email protected]
Subject: [Pharo-project] Input problems

Hi all,

after looking at the different input problems again it seems to me that they 
might all go back to problems with SharedQueue.
Attached is a small change file for all who regularly experience problems with 
loosing characters while typing or double pastes.

Please let me know if after filing in the change set the issues are fixed, less 
often or unchanged.

Thanks

Michael


_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Reply via email to