Simple cumulative timing question

[S]

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:

   1. 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?
   2. 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 
> Twitter:  @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 , 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 
> ), and offers several instructional videos there and on their YouTube 
> channel (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.
To view this discussion on the web visit https://groups.google.com/d/msg/e-prime/-/BN27WAeWypIJ.
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/20121110/27b9f3ab/attachment.htm>