Millisecond Forums

Yes, that is absolutely correct.

I agree. Inquisit's model doesn't seem to be a good fit here because

- a trial is designed to collect a single response and

- stimulus presentation and response collection are intricately linked (a <trial> is a self-contained unit which tries to ensure maximum precision within it; what happens between trials is another matter).

What you would need is some method to completely de-couple stimulus presentation and response polling, or at least something that keeps stimulus presentation intact *across* trials. I, frankly, don't see a fail-safe way to achieve this with Inquisit.

Yes, but Inquisit won't record responses during pre-/posttrialpause, if I understand the docs correctly.

Seems my problem boils down to not being able to

a) do a finite, yet lenghty loop of stimulus presentations within a trial while

b) polling multiple responses per trial

Guess it's Matlab then. Thanks for responding so thoroughly.

Unless there are other sources of error or drift, yes. But if you want to make absolutely sure to never miss a frame, you need to use pre- and posttrialpause (which are part of trialduration) to give Inquisit time for stim prep and cleanup. Again, the diagram mentioned previously should come in handy to clarify.

Let's just stay with the "yes" part when it comes to the observer's perspective - which should be the focus of interest for the experimentator. Disregarding afterimages of any sort, the visual stimulation from a trial will always end after a discrete amount of frames. Of course you can arbitrarily terminate some processes within the software on a very fine-grained discrete scale - such as response polling. At the observer end, however, a trial and all internal observer responses it evokes terminate along a rather coarse discrete timline determined by the monitor framerate.

That's reassuring. What happens when my trial is 4 frames long, i.e., 1/60*1000 msec and I set the timeout to exactly these 1/60*1000. Will the frame refresh and the timeout compete with each other? The scenario I'm thinking about is the graphics driver preparing the next refresh while Inquisit waits for the timeout to complete. At some point the next refresh is about to happen. At this exact moment Inquisit realizes that the timeout has come and it tries to update the frame buffer... too late because the next refresh just happened.

Or is Inquisit smart enough to realize that the timeout coincides with a refresh onset and adjust things accordingly? Meaning that it prepares the next trial right after it has put up the last frame of the previous trial while keeping to poll responses until the actual next refresh?

Yes and no.

Also yes and no. Of course, Inquisit can terminate response polling and the like after 55ms, thus terminating the trial. What it cannot do (and neither can any other software), is make your display do anything when it isn't ready to (i.e., when it is in the midst of a refresh cycle).

Not sure I personally like this idea, but you can do this now. Nothing prevents you from computing frame-perfect durations in ms based on the display.refreshinterval or display.refreshrate property. /timeout, /trialduration and the like do accept values and expressions. And for the stimulus presentation sequence there is also /numframes.

However, I don't see how any of that helps to solve the actual problem at hand.

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.

/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.

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?

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.

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.