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:<br><ol><li>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?</li><li>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). </li></ol>-- Thanks for advice and suggestions (which I promise to test before using in my experiments).<br><br>On Friday, November 9, 2012 3:16:26 PM UTC-6, McFarlane, David wrote:<blockquote class="gmail_quote" style="margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Yes, the diagrams in the manuals leave much to be desired.  That's 

<br>why I prefer plain math, such as I gave in my earlier reply.  Just 

<br>think through the math and it should all become clear; also, run some 

<br>exercises, log all the time audit measures, look at the outcome in 

the .edat files, and it should all make sense.

<br>

<br>Basically, you surmise correctly that if stimulus S is set to 

<br>Cumulative and follows an InLine that takes up some time, then 

<br>stimulus S will still end (or equivalently, the stimulus following S 

<br>will start) at the same time that it would have if the InLine were 

<br>not there, which is just what you want.  That is one of the beauties 

<br>of Cumulative timing mode.  The rest of your objects may then use 

<br>Event or Cumulative timing mode, as seems most appropriate for each 

<br>one.  Typically people use Cumulative on all the objects in their 

<br>Procedures in order to keep synchronized with external events or 

<br>equipment (e.g., fMRI volume scans), but yes if you want all your 

<br>other objects to last at least their full Durations regardless of 

OnsetDelays, then you should keep them at Event.

<br>

<br>BTW, more commonly people resort to the following sort of kludge:

<br>

<br>     Const  SDuration as Long = 1000

<br>     Dim  t0 as Long

<br>     t0 = Clock.Read

<br>     ' <the rest of your InLine goes here...>

<br>     c.SetAttrib "SDuration", SDuration - (Clock.Read - t0)

<br>

<br>And then use [SDuration] for the Duration of S.  I.e., they use of 

<br>bunch of extra inline code to adjust the stimulus Duration on the 

<br>fly.  But this is a lot of extra work, it fails to take advantage of 

<br>the timing facilities already built in to E-Prime objects, and is not 

<br>even as exact.  So I prefer your approach (and have done this in the 

past myself).

<br>

<br>I stress again, please do not believe anything that you read in the 

<br>manuals or here (not even from me), run your own tests and make sure 

that everything makes sense to you.

<br>

<br>-----

<br>David McFarlane

<br>E-Prime training 

<br>online:  <a href="http://psychology.msu.edu/Workshops_Courses/eprime.aspx" target="_blank">http://psychology.msu.edu/<wbr>Workshops_Courses/eprime.aspx</a>

<br>Twitter:  @EPrimeMaster (<a href="https://twitter.com/EPrimeMaster" target="_blank">https://twitter.com/<wbr>EPrimeMaster</a>)

<br>

<br>/----

<br>Stock reminder:  1) I do not work for PST.  2) PST's trained staff 

<br>take any and all questions at 

<br><a href="http://support.pstnet.com/e%2Dprime/support/login.asp" target="_blank">http://support.pstnet.com/e%<wbr>2Dprime/support/login.asp</a> , and they 

<br>strive to respond to all requests in 24-48 hours -- this is pretty 

<br>much their substitute for proper documentation, so make full use of 

<br>it.  3) In addition, PST takes questions at their Facebook page 

<br>(<a href="http://www.facebook.com/pages/Psychology-Software-Tools-Inc/241802160683" target="_blank">http://www.facebook.com/<wbr>pages/Psychology-Software-<wbr>Tools-Inc/241802160683</a> 

<br>), and offers several instructional videos there and on their YouTube 

<br>channel (<a href="http://www.youtube.com/user/PSTNET" target="_blank">http://www.youtube.com/user/<wbr>PSTNET</a> ) (no Twitter feed yet, 

<br>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.

<br>\----

<br>

<br>

<br>At 11/9/2012 04:03 AM Friday, FrankBank wrote:

<br>>Hi David,

<br>>Thanks for your response.  I looked over the help file

<br>>(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.

<br>>

<br>>In the meantime, I am looking at figure 9 in Chapter 3 of the user's

<br>>guide (page 90) that compares event mode and cumulative mode.  The

<br>>reason I thought cumulative would be good for the first slide -only-

<br>>was because that slide is the only slide in the procedure that is

<br>>blank (a white screen).  Looking at the user's guide it isn't clear to

<br>>me what is shown on the screen during delays.  Is it the previous

<br>>slide? A blank white screen?  It doesn't seem to say so I thought it

<br>>was a blank white screen.  Therefore I thought using cumulative mode

<br>>during my blank slide would seem the best choice, since the delay +

<br>>slide time would give me a consistent blank white screen duration

>(delay+ shortened slide 1 duration) across all trials.

<br>>

<br>>The rest of my slides in the procedure have stimulus presentations and

<br>>I would like to keep their durations fixed, so event timing for these

<br>>seemed the best idea.  I only seem to be getting consistent onset

<br>>delays with the first slide after the inline, so if their was some

<br>>anomalous delay for the later slides event timing would keep their

>durations equivalent.

<br>>

<br>>I feel like maybe I'm missing something here, so please let me know if

>that's the case.

<br>>thanks again,

<br>>Frank

<br>

<br></blockquote>

<p></p>

-- <br />

You received this message because you are subscribed to the Google Groups "E-Prime" group.<br />

To post to this group, send email to e-prime@googlegroups.com.<br />

To unsubscribe from this group, send email to e-prime+unsubscribe@googlegroups.com.<br />

To view this discussion on the web visit <a href="https://groups.google.com/d/msg/e-prime/-/BN27WAeWypIJ">https://groups.google.com/d/msg/e-prime/-/BN27WAeWypIJ</a>.<br />

For more options, visit <a href="https://groups.google.com/groups/opt_out">https://groups.google.com/groups/opt_out</a>.<br />

 <br />

 <br />