Millisecond Forums

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.

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?

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.

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.

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.