Millisecond Forums

Because

you leave no time for any responses whatsoever.

Aha! Thanks a lot for clarifying.

So with a refresh rate of 60 Hz and a trial that covers 4 frames, I'd set the timeout to 4 * 1/60 * 1000 = 66 milliseconds.

The trial would then look like

<trial TRIAL_main>
/ branch = [if (trial.TRIAL_main.response==57) trial.TRIAL_main]
/ responseframe = 1
/ responseinterrupt = trial
/ stimulusframes = [1=TEXT_A; 3=TEXT_B; 4=SHAPE_dummy]
/ timeout = 66
/ validresponse = ("a", 57)
</trial>

This appears to work, Inquisit records responses now. Allow me two questions:

(1) Inquisit constantly records "46" as the trial latency on trials where i pressed the space bar. Where does this value of 46 milliseconds come from?

(2) Should I incorporate some kind of tolerance value to guarantee that Inquisit will not wait too long (i.e., more than 1 frame) before ending the trial. I'm thinking 60 instead of 66 milliseconds.

Best wishes, Malte

I don't know. Might be a systematic delay induced by your keyboard, for example. Note that with a trial this short you are approaching typical measurement error sizes for some keyboards (they vary greatly).

You might want to try, but that may exacerbate #1 above.

Hi Dave, your hunch was spot on. I just tested latency recording with a Cedrus keypad which gave reasonable and, more importantly, variable latencies. Seems to be a Windows messaging issue indeed. The peculiar thing is that with /timeout = 66, the trial latency on noresponse trials is recorded as 46. A mystery.

My problem now is that with the Cedrus keypad I'm missing 30% - 40% of all button presses, on a normal keyboard between 70% and 80%. Most probably, those responses fall into the trial preparation/allocation or cleanup intervals and are not registered.

Do you have any suggestions on how to this could be avoided in what I try to do. My only idea so far would be prolonging the trial as in

/ stimulusframes = [1=A;3=B;5=A;7=B;9=A;...]

The obstacle being that in my actual experiment, "A" consists of five BMPs which makes me worry if this will cause too much precaluation and thus disrupt the 2-frame update intervals.

My second question would be: is there any way of terminating a trial which does not involve a user response besides the /timeout property?

Best wishes, Malte

This would be consistent with a loss / lag of one frame on a system running at 50Hz refresh rate (i.e., a 20ms refresh cycle). Could be either

- an off-by-one bug in /responseframe. What happens when with /responseframe=0 and /responsetime=0 respectively? What happens when you extend the timeout -- is the latency for non-responses still off by the same amount?

- a one-frame-lag induced by some other system component (driver, display hardware).

- something else entirely which I haven't thought off.

That would be my intuition as well. I have a gut-level feeling, though, that Inquisit may not be a particularly good fit for the particular type of study you're aiming to implement. Can't be sure about that, though, without further details (i.e., which are the variables of interest, relative to what are responses to be measured, etc.?).

/trialduration, but I don't immediately see how that would help. /trialduration fixes the trial's duration to the specified value (duh, I know), while /timeout specifies maximum duration. The way your trials are set up (/responseinterrupt), though, it shouldn't make any difference which one you use.

The data comes from my notebook (60Hz) on which I've done some more testing in the meantime. First observation I made was that the recorded latency scales linearly with the timeout. It is always "timeout-16" (yes, "minus"), at least for the dozen or so timeouts I've checked. 16 fits nicely with the refresh cycle of 16.6665 ms with a 60Hz refresh rate.

Conclusion is: you were right again, the /responseframe=1 attribute is causing the problems. One might say that it's not a bug but rather unexpected behavior. While the frame count in the /stimulusframes property starts at 1, /responseframe starts at 0. Setting /responseframe=0 or /responsetime=0 has latency and timeout become identical.

May very well be true. I had initially thought about using Matlab+PschophysicsToolbox for this special use case, but I reckoned it such a simple setup that I chose to try Inquisit first. I only need two stimuli to alternate at about 33Hz for several minutes and to record keypresses and their timings during the whole thing. Response timing accuracy is not the top priority since responses should usually be seperated by seconds, not milliseconds. The only crucial thing is that there must not be much disruption in the 33Hz flicker frequency.

It's ironic that I have everything working in Inquisit (realtime priority and the like) except for response recording. BUT with /responsetime=0 the lost keypress problem has improved greatly. Inquisit only misses about 20% of keypresses via a normal keyboard. I'll try with the Cedrus now. 10% missed responses might be acceptable.

One more question for those with insight into the Inquisit code. If in a trial I have

/ stimulusframes = [1=A; 3=B]

The trial will then span 3 frames. In frame 4, given nothing takes too long after the onset of frame 3, the next frame (i.e., frame 4) should display the first frame of the following trial.

If the trial further contains

/ timeout = 40

and with a refresh rate of 60 Hz, response recording will stop at some point during the third frame, thus bearing the risk of missing keypresses.

What happens when I use

/ trialduration = 40

instead? Will response recording stop after 40 msec just as with the /timeout property?

/timeout vs. /trialduration should not make any difference here. As detailed previously, /timeout determines *maximum* trialduration (i.e., the trial may terminate earlier if applicable), /trialduration *fixes* duration to the specified value (i.e., the trial *will not terminate* earlier).

Giving the diagram in the "How to control trial duration and inter-trial intervals" topic in the docs another look might help to clarify.

I am aware of the flow diagram in the docs. The key issue to me is that both /timeout and /trialduration work with a millisecond metric while the actual metric for the experimentator is always discrete, i.e. frames.

Consequently, /trialduration=55 will never be accurate on a 60Hz system. The actual trial length will always be at least 66.665 msec. Hence, physical trial length and defined trial length are not identical, thereby making it impossible to precisely sync response recording to trial duration.

Inquisit handles this very nicely in parts by introducing the frames metric for various trial properties. Unfortunately not for the only two properties that allow to end a trial. I'd love to see /timeoutframe and /trialdurationframes in the next release.

Anyway, thanks for your help, Dave.