We had some problems with 4.0.5 where response RTs were all being recorded as ‘000’ - not every time SuperLab ran, just randomly.
So, we have just tried upgrading to 4.0.6 and there seems to be a random delay after responding to stimuli by keypress and the next event/trial being presented. This delay can be several seconds.
I’ve reproduced this with a simple single block, single trial, three event text stimuli experiment that doesn’t save responses. I’ve also reproduced this on three different computers with three different builds, one of which is just a fully patched vanilla Windows XP machine (no AV software or other apps).
We need to either run 4.0.5 with reliable RT recording or 4.0.6 without random delays.
Sorry for the delay. I checked around the office and no one has a voice mail or message from John H.
I looked at the experiment, ran it a few times but never got 000 reaction time. Do you have a sample data file?
BTW, I noticed in the sample experiment that you posted that all three events are part of the same trial. If they are separate trials, then you really should have three trials and three events instead. In your sample, all RTs are being measured relative to the onset of the first event – the time is not being reset every time.
Better yet, try using stimulus lists. I modified your experiment to use a stimulus list. Let me know if you have questions. Also, feel free to call me; FYI, I’ll be out of the office from Thursday noon (California time) until Tuesday morning.
Thanks for getting back to me. I do appreciate that but did you read the thread before replying?
As I explained the sample I provided wasn’t the real experiment it was just meant to illustrate the particular problem with SuperLab freezing in the simplest possible way (not the separate problem with timing).
Here are the details of what happens when I run the sample I posted (again):
Here’s a simple setup using 4.0.6. When I run this:
The first word is presented and pressing a key causes the second word to be displayed immediately as expected
Pressing a single key while the second word is on the screen causes a random pause before the third word is presented
Pressing a single key while the third word is on the screen has the same undesired effect.
I now have three separate problems with SuperLab depending on the version we use to run experiments. It’s looking very unreliable but I’m willing to pursue a solution, starting with one to the problem above.
Do you recommend I carry on posting here or would you prefer me to post a bug report?
I’ve re-run the experiment that you sent me and I am not seeing any of the pauses that you are describing.
The best course of action is actually for you to call me from a phone that’s near the computer that has the experiment, and with the computer connected to the Internet. We use screen sharing technology for taking a look at your computer and seeing exactly what you’re seeing. Plus, I’d be able to see your actual experiment instead of the sample that you posted here.
Phone number is 1.800.233.7871. If you are overseas, it’s 1.310.548.9595, but I’ll be happy to call you instead if you email me your phone number in a private message.
Thanks for the responses. I’m away on leave now until 31st March. I’ll post info back in response to Hank then when I have the technical details to hand.
I’ve given this version a quick test and it seems to be working OK.
I won’t have a chance to see if we still get the problem of some RTs being recorded as ‘000’ as we had to switch a few projects to E-Prime. We’ll return to SuperLab at some point though and check this out more thoroughly.
I’ll send you an email with all the machine technical information in case that’s of any use to you.
The 4.0.6b update still had some obscure issues on single processor machines, so we’ve reverted to the 4.0.5 behavior on single-core machines with the 4.0.7 update. I apologize for the trouble this has caused.