The Script
<ep> <cr> <fd 1> <d 119> <t 1500> <id keyboard>
<dbc 210210210> <dfs
36> <fbd 30> <dwc 0 > <vm
1024,768,768,16,60> <clfb> <fbd 30> <rcot> <eop>
! This is a very simple
demo of a lexical decision task;
! last
edited on
! Item number AB;
! A=condition (1=word,
2=non-word);
! B=Trial number;
0 ”Press SPACEBAR to start”;
+11 * “RABIES”;
-22 * “BRANTLY”;
-23 * “SKELVE”;
+14 * “JUMP”;
0 ”The END! Thank you for your participation”;
The Output File
Subjects incorporated to
date: 001
Data file started on
machine EVO
**********************************************************************
Subject 1, 11/07/2005
20:40:54 on EVO, refresh 16.66ms, ID JJC
Item
RT COT
11 -1500.00 0.00
22
345.58 4032.01
23
-236.28 6914.40
14
218.02 9680.15
The Explanation
As you can see from the COTs, the trials are no longer of fixed duration. Instead, they vary based on both the time out
value and the subject’s response time.
From the top of the subject’s output we know that the refresh
interval/tick duration is 16.66 ms. From
the header of the script, we know that the default delay is 119 ticks. The default frame duration is 1 tick, but
this will not matter b/c there is only 1 frame per item. The feedback duration (fbd)
is 30 ticks (default is 35 ticks if not specified in the header). Let’s now dissect the timing for a few
trials.
The first trial lasted
4032 ms (COTs of 4032 – 0). RABIES was presented for 1500ms (i.e., the
participant didn’t respond and therefore the full time out was used). This is 1500/ 16.66 = 90.04 ticks. You can never have partial ticks. They are always rounded up. Therefore RABIES was initially presented for
91 ticks. There are 2 ticks delay (with
RABIES still on the screen) to assemble the clear feedback. The feedback is up for 30 ticks (RABIES is
erased when this starts). Then there is
a 119 tick delay.
91 + 2 + 30 + 119 = 242
ticks. 242 ticks * 16.66ms = 4031.72ms
[actually, my refresh interval is more like 16.661 so the true duration should
be 4031.96]
The second trial lasted 2882.39ms (COTs of 6914.40 – 4032.01).
BRANTLY was presented for 345.58 / 16.66 = 21 (20.7) ticks. BRANTLY remains on the
screen for 2 ticks while clearfeedback is assembled. 30 ticks of feedback. 119 ticks of delay
21 + 2 + 30 + 119 = 172
ticks. 172 ticks *
16.66 = 2865.52ms. NOTE: It
appears that this trial took one tick longer than it should have. Jonathan has indicated in the help files that
there is no guarantee for exact timing with clearfeedback. On some machines, it may take longer than 2
ticks to assemble the clearfeedback. On this trial it appears that the feedback
delay may have required three ticks. Of
course, if you are using response contingent timing, you probably don’t care
about having exact trial durations as you have already allowed this to vary
based on subject response.
The third trial lasted
2765.75ms (COTS of 9680.15 – 6914.40).
SKELVE was presented for 236.28 / 16.66 = 15 (14.2) ticks. SKELVE remains on the screen for 2 ticks
while clearfeedback is prepared. 30 ticks of clearfeedback (erasing SKELVE). 119 ticks of delay.
15 + 2 + 30 + 119 = 166
ticks. 166 ticks * 16.66ms = 2765.56