Critical time delay after a subject's input

Vaaal valerio.biscione at gmail.com
Mon May 6 21:00:50 UTC 2013


Hello, I am trying to solve a timing problem. When the frame waits for the 
subject to press a button, a PreRelease procedure seems to be impossible 
for e-prime. This adds an unwanted onset delay to the next frame. This is 
quite strange to me: couldn't e-prime start loading the following frame 
from the beginning of the first frame? 
Anyway, on the documentation (chapter 3, section 3.3.1.1, just before the 
next section) they address exactly this problem. It is written:
"Similarly, PreRelease time can not be honored by E-Prime in the case that 
the current object is terminated by a response input (i.e., because the 
system cannot possibly predict when a subject will respond, it cannot react 
to the response until after it occurs). 
This also is typically not a problem for most paradigms, as once a display 
is terminated, subsequent displays are not often viewed as time critical. 
Note, even if they are, they are minimally likely to be out of sync with 
the vertical refresh cycle, 
and incur some amount of unwanted delay. For paradigms in which this is a 
problem, it is recommended that the input specifications be set so that the 
display is NOT 
terminated upon response. This will allow the response to be time-stamped, 
scored, and logged properly, and the timing of the display sequence will 
remain accurate."


I don't clearly understand the solution proposed here. I am exactly in the 
case in which, after the subject response, the timing precision is 
critical. I would like to have an onset delay close to zero, if this is 
possible. What does it mean that the display should NOT be terminated upon 
response? If my design requires that, what should I do? I came up with 
something, but first I need to be more specific. 
In particular, imagine that I have 3 frames. Frame1 waits for the subject 
to press a button. After that, Frame2 appears and stays on the screen for a 
duration specified in an attribute (DurationA), then Frame3 appears on the 
screen.  Assuming that the OnsetDelay of Frame3 is negligible, but the 
OnSetDelay of Frame2 goes from 15 to 35ms (too much for my purpose) (this 
onsetDelay is exactly what I want to reduce as much as possible).
I want to be sure that the time from the pressure of the button in Frame1, 
until the start of Frame3, is exactly DurationA (best case, let's call it 
CASE1). Let's call the REAL duration from the pressing of the button until 
the start of Frame3 REALdurationA. Can I manage to have DurationA (the 
supposed time from the pressing of the button to the start of Frame3) 
roughly equal to REALDurationA? At least, I want to calculate REALdurationA 
(second best case, CASE2). 


I came up with this idea. 
I could use the cumulative timing system. After frame1, there is a delay 
before the onset of frame2 (from 16ms to 30ms). With the cumulative timing 
mode, the frame2 is on the screen for durationA-onSetDelay time. But the 
total time from the pressure of the button in Frame1, until the onset of 
Frame3 (which onsetDelay is assumed to be close to 0) should be equal to 
DurationA. This means that DurationA is roughly equal to REALDurationA. My 
question is: is this reasoning correct, or I made some silly mistake?

Now, assume that the problem cannot be addressed, so I'll settle for just 
knowing the REALDurationA (CASE2).  Like before, assume that the onsetDelay 
of Frame2 is negligible. Would the REALDurationA just be 
DurationA+Frame2.onsetDealy, or there is still something else? For example, 
maybe there are more milliseconds from the moment in which the button is 
pressed until the moment frame1 ( NOT 2) disappears, and these milliseconds 
will not be recorded in Frame2.OnsetDelay.


If this is specified later in the text, I apologize and come back to 
reading the manual.


Thank you very much,
Valerio

-- 
You received this message because you are subscribed to the Google Groups "E-Prime" group.
To unsubscribe from this group and stop receiving emails from it, send an email to e-prime+unsubscribe at googlegroups.com.
To post to this group, send email to e-prime at googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msg/e-prime/-/q8Pf1O7k4rMJ.
For more options, visit https://groups.google.com/groups/opt_out.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listserv.linguistlist.org/pipermail/eprime/attachments/20130506/cba5b08c/attachment.htm>


More information about the Eprime mailing list