Hi,
Recently I have done an experiment, and i found that the latencies of some subjects were minus, like -1, or -3. So why did the latency appear minus?It seemed to me very strange.
Hi Shallot,
I've never seen Inquisit report negative latencies. This almost certainly points to a technical problem with the machine subjects were run on (e.g. a faulty hardware driver). Anyway, can you give us some more info about the actual experiment (e.g. general design, inputdevice settings, trial setup, desktop or web, etc.)? Also, can you post a datafile showcasing the problem? That might help in figuring out what happened here...
~Dave
"To understand recursion, you must first understand recursion." - Unknown Zen Master
Dear Dave,
I attached the script and also a sample of datafile. i tried to replicate the implicit priming paradigm, using voice input. The system is.Windows XP, with updated version of sound card driver. I don't know why the latencies sometimes appeared zero and even minus.
I have a question about how the Inquisit records the latency. Does it begin to record after the appearance of the stimuli in a trial?
Shallot:I have a question about how the Inquisit records the latency. Does it begin to record after the appearance of the stimuli in a trial?
By default Inquisit starts measuring latencies once the stimulus presentation sequence on a given trial has been completed. Consider this example:
<trial mytrial>/ stimulustimes = [0=prime; 250=mask1; 500=target; 750=mask2][...]</trial>
This trial would show a prime at T0, followed by a mask 250 ms into the trial, followed by a target stimulus 500 ms into the trial (i.e. 250 ms after the mask), followed by another masking stimulus 750 ms into the trial (i.e. another 250 ms after the target stimulus). By default, Inquisit will start listening for a response as soon as mask2 has been displayed (i.e. 750 ms into the trial). In other words, latencies will be measured relative to the onset of mask2. However, in a case like the one described here, you usually want to measure latencies relative to the onset of the target stimulus (500 ms into the trial). To do this, you must make use of either Inquisit's '/ responsetime' or '/ responseframe' attribute:
<trial mytrial>/ stimulustimes = [0=prime; 250=mask; 500=target; 750=mask]/ responsetime = 500[...]</trial>
Hope this helps,
Shallot:I attached the script and also a sample of datafile. i tried to replicate the implicit priming paradigm, using voice input. The system is.Windows XP, with updated version of sound card driver. I don't know why the latencies sometimes appeared zero and even minus.
Thanks for providing these. Just a few quick remarks:
(1) Something's fishy with the responsewindow definitions all over your script:
/ response = window(1000,0,500hz)
Note that you're assigning the window a width of zero which is (a) "illegal" (width needs to be a positive integer --check the documentation) and (b) probably not what you want. I'm unsure what these settings will do to the latency measurement.
(2) We've already discussed that some systems may be problematic in handling voice input. You might want to check if you can replicate the problem with other input devices (e.g. keyboard or mouse).
Thank you very much!
1)The responsewindown definitions are set to make a 500HZ warning sound appear in the 1st second after the presentation of the stimuli if the the subject does not response to the stimuli within 1s. Maybe is it better to set as /response = window (500,1000, 500hz)?
2)I will check the problem using other input devices. I think it's something only related to voice input, because i also have never seen negative latencies using other input devices.
Shallot
Shallot:1)The responsewindown definitions are set to make a 500HZ warning sound appear in the 1st second after the presentation of the stimuli if the the subject does not response to the stimuli within 1s. Maybe is it better to set as /response = window (500,1000, 500hz)?
To be honest, I'm not an expert when it comes to Inquisit's responsewindow facilities. I rarely have use for them and thus haven't quite gotten my head around these features. That said, I would simply integrate the 500Hz warning signal with the regular stimulus presentation sequence (via '/ stimulustimes' and proper '/ responsetime' and '/ responseinterrupt' settings).
Shallot:2)I will check the problem using other input devices. I think it's something only related to voice input, because i also have never seen negative latencies using other input devices.
Please let us know what you find!
Thanks,
hi,
i have already checked the problem but i didn't find negative latencies using other inputdevices. The negative latencies might be related to the problems with voicekey.
Also another problem, the sounds recorded by the inquisit are sometimes incomplete. Will lengthening the posttrial duration solve the problem?
Shallot,
I'll investigate to see if I can figure out this issue.
-Sean
Dave: This almost certainly points to a technical problem with the machine subjects were run on (e.g. a faulty hardware driver).
This almost certainly points to a technical problem with the machine subjects were run on (e.g. a faulty hardware driver).
More likely, this is just a regular old Inquisit bug. I don't think anyone has tested the combination of voicerecord and the response window before, so I wouldn't be shocked if there was some funkiness there.
I've just uploaded a new release of Inquisit 3.0.5.0 that should fix the voicerecord issues you've reported (both the freezing and the incorrect latencies). You can download it from the following link:
http://www.millisecond.com/download/Inquisit_3050.exe
This is not the standard download link - I want to give this more testing before releasing this as an official build.
Give it a try and let me know if you still encounter problems.
Regards,Sean
Thank you very much, Sean. I have tried and the problems did not appear.