Simple cumulative timing question

Tue Nov 13 17:56:15 UTC 2012

1) Yes, the advice in *footnote 10* on p. 99, section 3.4.2.1, of the 
original (& superiror) E-Prime User's Guide still applies:  For exact 
visual stimulus durations, set stimulus Durations at half a refresh 
duration before the desired duration.  (Note that the footnote 
supercedes the "10 ms" rule of thumb in the main text!)

2) You surmise correctly.  If you think through the simple math of 
Cumulative timing mode, you will see that the advice above does *not* 
apply here.  For Cumulative timing mode, the TargetOnsetTime of the 
next stimulus is based on the TargetOnsetTime of the current 
stimulus, which, *by design*, bears no relation to the screen 
refresh.  Timing things by screen refresh works only for stimuli that 
have OnsetSync set to Vertical blank, and use Event timing mode.

And the usual disclaimer:  Test all this for yourself (preferebly 
using a photodetector and oscilloscope), and also consult directly 
with the fine folks at PST Web Support.

-----
David McFarlane
E-Prime training 
online:  http://psychology.msu.edu/Workshops_Courses/eprime.aspx
Twitter:  @EPrimeMaster (https://twitter.com/EPrimeMaster)

At 11/10/2012 01:58 PM Saturday, S wrote:
>Thanks for explaining more about  the uses for cumulative timing, I 
>usually use event timing, because that's normally most important to 
>me, but recently have needed to use cumulative timing for 
>longer-term timing accuracy of trial & block durations. I have 
>related questions about  event  and cumulative timing, and combining 
>them. If I have a visual stimulus what I want displayed for 100 ms 
>(6 refresh cycles at 60 hz) and use event timing for this object, 
>E-Prime documentation recommends setting the duration of that object 
>to 90 ms to minimize the chance that E-Prime will miss detecting a 
>refresh (a little more than half a fresh cycle to watch for the next 
>vertical blank). I've tested this, and on our PCs I've found that it 
>does reduce missed refreshes (though I've found subtracting 5 rather 
>than 10 ms works more consistently).  If I set the visual display 
>duration to 100 ms, the onset to onset time (to the following 
>object) will occasionally be 116 ms, but that almost never happens 
>if I set the duration to 90 or 95 ms. I have the following two 
>questions about event and cumulative timings:
>    * Is this adjustment (setting duration to about half a refresh 
> less than desired target duration) generally a good practice to 
> achieve the most consistent event timing durations for visual displays?
>    * How does this practice need to be reconsidered when using a 
> combination of event and cumulative timings? I've used only one or 
> the other, and have always set duration to the exact value I want 
> when using cumulative timing, but usually 5 ms less when using 
> event timing (combined with onset syncs and no clear after).
>-- Thanks for advice and suggestions (which I promise to test before 
>using in my experiments).
>
>On Friday, November 9, 2012 3:16:26 PM UTC-6, McFarlane, David wrote:
>Yes, the diagrams in the manuals leave much to be desired.  That's
>why I prefer plain math, such as I gave in my earlier reply.  Just
>think through the math and it should all become clear; also, run some
>exercises, log all the time audit measures, look at the outcome in
>the .edat files, and it should all make sense.
>
>Basically, you surmise correctly that if stimulus S is set to
>Cumulative and follows an InLine that takes up some time, then
>stimulus S will still end (or equivalently, the stimulus following S
>will start) at the same time that it would have if the InLine were
>not there, which is just what you want.  That is one of the beauties
>of Cumulative timing mode.  The rest of your objects may then use
>Event or Cumulative timing mode, as seems most appropriate for each
>one.  Typically people use Cumulative on all the objects in their
>Procedures in order to keep synchronized with external events or
>equipment (e.g., fMRI volume scans), but yes if you want all your
>other objects to last at least their full Durations regardless of
>OnsetDelays, then you should keep them at Event.
>
>BTW, more commonly people resort to the following sort of kludge:
>
>      Const  SDuration as Long = 1000
>      Dim  t0 as Long
>      t0 = Clock.Read
>      ' <the rest of your InLine goes here...>
>      c.SetAttrib "SDuration", SDuration - (Clock.Read - t0)
>
>And then use [SDuration] for the Duration of S.  I.e., they use of
>bunch of extra inline code to adjust the stimulus Duration on the
>fly.  But this is a lot of extra work, it fails to take advantage of
>the timing facilities already built in to E-Prime objects, and is not
>even as exact.  So I prefer your approach (and have done this in the
>past myself).
>
>I stress again, please do not believe anything that you read in the
>manuals or here (not even from me), run your own tests and make sure
>that everything makes sense to you.
>
>-----
>David McFarlane
>E-Prime training
>online: 
><http://psychology.msu.edu/Workshops_Courses/eprime.aspx>http://psychology.msu.edu/Workshops_Courses/eprime.aspx 
>
>Twitter:  @EPrimeMaster 
>(<https://twitter.com/EPrimeMaster>https://twitter.com/EPrimeMaster)
>
>/----
>Stock reminder:  1) I do not work for PST.  2) PST's trained staff
>take any and all questions at
><http://support.pstnet.com/e%2Dprime/support/login.asp>http://support.pstnet.com/e%2Dprime/support/login.asp 
>, and they
>strive to respond to all requests in 24-48 hours -- this is pretty
>much their substitute for proper documentation, so make full use of
>it.  3) In addition, PST takes questions at their Facebook page
>(<http://www.facebook.com/pages/Psychology-Software-Tools-Inc/241802160683>http://www.facebook.com/pages/Psychology-Software-Tools-Inc/241802160683 
>
>), and offers several instructional videos there and on their YouTube
>channel 
>(<http://www.youtube.com/user/PSTNET>http://www.youtube.com/user/PSTNET 
>) (no Twitter feed yet,
>though).  4) If you do get an answer from PST staff, please extend
>the courtesy of posting their reply back here for the sake of others.
>\----
>
>
>At 11/9/2012 04:03 AM Friday, FrankBank wrote:
> >Hi David,
> >Thanks for your response.  I looked over the help file
> >(GetNextTargetOnsetTime, etc) and had a hard time understanding how it
> >all works.  I'll try again though and see if I can make sense of it.
> >
> >In the meantime, I am looking at figure 9 in Chapter 3 of the user's
> >guide (page 90) that compares event mode and cumulative mode.  The
> >reason I thought cumulative would be good for the first slide -only-
> >was because that slide is the only slide in the procedure that is
> >blank (a white screen).  Looking at the user's guide it isn't clear to
> >me what is shown on the screen during delays.  Is it the previous
> >slide? A blank white screen?  It doesn't seem to say so I thought it
> >was a blank white screen.  Therefore I thought using cumulative mode
> >during my blank slide would seem the best choice, since the delay +
> >slide time would give me a consistent blank white screen duration
> >(delay+ shortened slide 1 duration) across all trials.
> >
> >The rest of my slides in the procedure have stimulus presentations and
> >I would like to keep their durations fixed, so event timing for these
> >seemed the best idea.  I only seem to be getting consistent onset
> >delays with the first slide after the inline, so if their was some
> >anomalous delay for the later slides event timing would keep their
> >durations equivalent.
> >
> >I feel like maybe I'm missing something here, so please let me know if
> >that's the case.
> >thanks again,
> >Frank

-- 
You received this message because you are subscribed to the Google Groups "E-Prime" group.
To post to this group, send email to e-prime at googlegroups.com.
To unsubscribe from this group, send email to e-prime+unsubscribe at googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.