Simple cumulative timing question

David McFarlane mcfarla9 at msu.edu
Fri Nov 9 21:16:11 UTC 2012


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.
For more options, visit https://groups.google.com/groups/opt_out.



More information about the Eprime mailing list