MAPLE-Lab / auditory-research-suite

Automatically exported from code.google.com/p/auditory-research-suite
0 stars 2 forks source link

Hanging as a result of many taps #26

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
There are two issues with the recording of taps (the other is Issue 25). There 
is some common information pertinent to both, which is included at the end of 
each entry.

Case 1 - If a participant makes around 33 or more taps, the program hangs (i.e. 
the trial can’t complete since the buttons are still greyed out).  This issue 
is concurrent with the issue 25 where no taps are recorded (see Case 2). That 
is, if the program is correctly recording participant taps, making 33+ taps 
will not hang up the program. Only when the program stops recording participant 
taps can it hang up, even though the taps are not registering. Additionally, if 
in the 2nd trial we make less than 33 taps, the program does not hang (although 
these taps are not recorded).  The relevant files documenting this instance of 
taps that are failed to be recorded but do not cause the program to hang are 
included with issue 25.

Note: if the suppression window is being used (which we do by default, the 
current value is suppressionWindow=50), then not all taps are registered to 
tapping file(…Taps.txt). This is exactly what it is designed to do (hitting 
the pad often causes “double taps” and we want to record only the first of 
these).  However I’m mentioning it here since it appears that all of the taps 
(suppressed or otherwise) contribute to this hanging issue.  Perhaps a certain 
number of taps fills a buffer or something. 

--- Common information copied over from issue 25 ----

To try and narrow down the number of variables to consider, we tested a variety 
of builds on a variety of operating systems.  Builds 222, 178, 159 all display 
this problem when running 10.9 (we’ve tested 10.9.2 and 10.9.3).  And we’ve 
observed this when using either a MIDI keyboard or our (more typical) drumpad 
setup.  We have not seen this problem when using build 222 on 10.6.8 and/or 
10.8.3.  Therefore it appears the issue is one of changes to the OS in 10.9.3.

Currently, we have moved to 10.9.2 for most testing, but kept a few 
“legacy” computers running 10.6 for compatibility with the older versions 
of this software (which used Apple sounds that were not longer accessible in 
later OSs).  To streamline operations we decided a while back to pick a new 
“target” OS and then just focus on that.  I need to purchase some new 
computers soon, and it appears Apple is now up to 10.9.4!  I’m fine up 
updating the newer computers to a newer version of the OS  - obviously I just 
want to make sure the MIDI stuff works OK there.

Original issue reported on code.google.com by schutz.m...@gmail.com on 4 Jul 2014 at 7:53

Attachments: