Skip to content

Fixed trial duration

Make every trial last exactly the same time whether the response comes early, late, or not at all.

Some designs need a metronomic trial rhythm: physiological recording that must stay aligned to stimulus events, paced tasks where fast responders would otherwise race ahead, or any study where time-on-task must be identical across participants. The naive setup fails because a keyboard response normally ends the trial the moment it is given, so trial length tracks response speed. Skip this construction when responses should advance the experiment; a fixed pace forces slow participants to time out.

typestimFormattitlecontentstim1ITIresponseWindowresponseOptionskeyboardkeybutton1
instructionsWord or made-up?Press A if the letters spell a real word and L if they do not. The task runs at a fixed pace: the next item appears on the same rhythm however quickly you answer.NEXT
testwordGARDEN5002000waitResponseWindowa la
testwordFLINDER5002000waitResponseWindowa ll
testwordWINDOW5002000waitResponseWindowa la
testwordPLOMB5002000waitResponseWindowa ll
testwordMARKET5002000waitResponseWindowa la
testwordTRENDLE5002000waitResponseWindowa ll

Two columns share the timekeeping. The numeric responseWindow of 2000 opens when the stimulus appears and closes 2000 ms later; on its own it only caps the slow end, because an early keypress would still end the trial at once. The waitResponseWindow flag in responseOptions closes the fast end: the response is recorded when it is made, but the trial stays open until the window itself closes. Together they pin every trial to exactly 2000 ms from stimulus onset, and a trial with no response records timeout at the same moment the others end.

ITI adds a constant 500 ms blank before each stimulus, so the full cycle is 2500 ms per trial. It must be a plain number here; the min_max and a|b|c forms are redrawn per presentation and would reintroduce exactly the variability this recipe removes. With presTime left out, the word also stays visible for the whole window, so the display duration is as constant as the trial.

Spelling matters twice in responseOptions. The flag is matched case-sensitively against the raw cell, so waitresponsewindow does nothing and the trials quietly go back to ending on response. And it is not waitTimeout, which does the opposite job: that flag stops the timeout from closing the trial, which would let a missed response hold the screen indefinitely.

  • Flash the stimulus briefly while keeping the fixed pace: add presTime 300; trial length still comes from the responseWindow timeout.
  • Fill the pre-stimulus gap with a cross by setting fixation to the exact token ITI, so the 500 ms reads as a fixation period rather than a blank.
  • If you add feedback, give every outcome a message (including timeout:) and a fixed feedbackTime; a feedback screen that only some trials trigger, or one ended by a NEXT button, makes trial length variable again.
  • Block anticipations without changing the trial length by using responseWindow min:200;max:2000; presses in the first 200 ms are buffered until the minimum ends.