Simple cumulative timing question

[FrankBank]

I just want to make sure that I understand how the cumulative timing works. For example, say you had a trial procedure with several slides but that began with an inline that was causing onset delays (for the first slide).  Then you could set the timing of that first slide to cumulative and the delay will be  absorbed by that slides total duration time setting.  Meanwhile, the rest of the slides in the procedure can be left on the event timing setting, since they have no onset delays.  So, as long as the first slide is, for example, just a blank pause or something, then cumulative timing would work well because the total blank screen time would remain the same at the beginning of the procedure.  Do I have this right?

thank you for any assistance/reassurance!

[David McFarlane]

First & foremost, you can figure this out by doing some test for
yourself (and you should never believe what anyone tells you
anyway). Just run your exercise and inspect all the time audit
measures (see
http://groups.google.com/group/e-prime/browse_thread/thread/39e899d3457d4917
) from your various stimulus objects.

Of course, you still want some theoretical understanding. For that,
start with Chapter 3 of the original E-Prime User's Guide (or try
Chapter 4 of the revised edition). Then look at the
GetNextTargetOnsetTime and SetNextTargetOnsetTime topics in the
E-Basic Help facility. From that, let's infer that E-Basic holds a
hidden NextTargetOnsetTime variable. And note that Timing Mode
merely determines the baseline for setting NextTargetOnseTime from
the stimulus Duration -- i.e., Event uses OnsetTime for the baseline,
whereas Cumulative uses NextTargetOnsetTime (or TargetOnsetTime,
depending on how you want to think of this). From there, it is just
simple arithmetic.

So suppose you have an InLine, followed by Slide1 (set to Cumulative
timing mode), followed by Slide2. And suppose that Slide1 one does
*not* get terminated by some event (e.g., response or sound End
Action). In that special case, the following holds:

When Slide1 starts execution,
Slide1.TargetOnsetTime = NextTargetOnsetTime
NextTargetOnsetTime = NextTargetOnsetTime + Slide1.Duration

Then when Slide2 starts execution,
Slide2.TargetOnsetTime = NextTargetOnsetTime
...

So from that you can see that, yes, what you surmised was
correct. By contrast, using Event timing mode, the following would hold:

When Slide1 starts execution,
Slide1.TargetOnsetTime = NextTargetOnsetTime
...
NextTargetOnsetTime = Slide1.OnsetTime + Slide1.Duration

And you can take it from there.

BTW, why not just use Cumulative timing mode for all your stimulus
objects in the Procedure? In most cases, that would seem more natural.

And again, test all this for yourself, never take anyone's word for
anything, not even mine.

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

[FrankBank]

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

[David McFarlane]

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

[FrankBank]

Thanks for your response, I think I'm getting the idea now.  One last question though: if the onset delay lasts several refresh cycles, what do the pixels on a CRT monitor display during this time? 

[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).

[FrankBank]

 Hi Scott, I'm just wondering where you saw in the E-prime documentation to set the duration less than (rather than exactly) at some multiple of the refresh rate?  Maybe I'll try doing that as well.  My (perhaps faulty) understanding of the E-prime documentation is a little different.  I thought what happens when you set the duration to less than an exact multiple of the refresh cycle is that you end up with a percentage of your trials displayed at the +1 refresh cycle and -1 refresh cycle that bounds that chosen duration.

So, say you used 90 ms in your case.  Your upper bound refresh cycle is at 100ms and lower is at 100-16.7 = 83.3 ms.  The distance of your chosen duration from these two points determines the percentage of trials that will be of either the lower or higher duration.  So then:
90 - 83.3 = 6.7 ms.  Then divide that by the refresh cycle: 6.7/16.7 = 40%.  Since it is  40% of the distance between refresh cycles you'd end up with 40% of your trials at 100 ms and 60% at the low end of 83.3 ms.  If you used 95 ms instead you'd get 95 - 83.3 = 11.7 and 11.7/16.7 = 70% so 70% of your trials would be 100 ms in duration and 30% at 83.3 ms.  That is how i read it anyways, would be very interested to hear others thoughts! 

[FrankBank]

Scott, i just had one more idea about your issue.  Is it possible your refresh rate is not exactly 60hz, but something very close?  If so then when you set it to 100 ms and get occasional 116 ms times maybe that's because the actual refresh rate of your monitor is slightly higher than 60hz so that the refresh cycle x 6 = something a little less than 100 ms (based on my previous post about percentages).  Then, when you drop it to say 90 or 95 ms you are under the 6 cycle limit and so you start getting a very high percentage of full 6 cycle duration trials.  If something like this is the case than perhaps your actual multiple of a refresh cycles is in the range between 95 and 100 ms and once you find it exactly you will have consistent durations (somewhere in that range) across all trials.  Just an idea.

[Scott]

Sorry if I wasn't sufficiently clear. This adjustment is ONLY done for EVENT timing.  In fact, what I'm asking about is how to take this into account, exactly what to do, when using a mixture of event and cumulative timings. Based on your response, I still might be saying something wrong -- if so, I'm sorry to to be unclear. I really thought that this ~10 ms 'adjustment' was obvious in the documentation, though I also know that the documentation is old and could be outdated, and one cannot always just following anyone's advice, even PST's. What I'm referring to is printed in bold in the E-Prime User’s Guide Chapter 3: Critical Timing (page 99):

The equation to use for determining what stimulus duration to specify in E-Prime is as follows:
Stimulus Duration to Specify = (Refresh Duration ms/cycle * Number of cycles) - 10ms

Part of the reason for doing this, as I understand it, is because one can never assume that  the refresh rate will ever be exactly 60 hz (or anything else).

This is what I meant to say, but maybe I did not, because the documentation that I have seen seems pretty explicit about this, for EVENT timing (in fact they explain this for most of 2 pages of Chapter 3). Now that I have hopefully clarified what I was trying to say, please tell me: Has this recommendation changed? If so, someone please explain and set me straight. I usually have done this (except in certain circumstances), starting with E-Prime 1 and continuing with E-Prime 2. Maybe you have more current documentation, FrankBank. What do you see for actual OTO timings in your data when you have used EVENT timing mode, across several hundred trials or so when setting a 100 ms stimulus duration for 100 ms? If it always works like that (with no extra refresh cycles), then I suppose there's no reason to do it differently.

[Scott]

PS -- My original response was to David's suggestion above setting one object for Cumulative and then: "The rest of your objects may then use
Event or Cumulative timing mode, as seems most appropriate...", so I was asking about using this combination of timing modes. I'm sorry if I've confused this thread about Cumulative timing mode with another question (meant to be related) about Event timing mode. I suppose David will explain how simple math can answer my question. I've been reluctant to mix timing modes in a trial or experiment because I wasn't sure about how to set durations for various objects set for different timing modes. I thought that the documentation recommended a "good rule of thumb..." for setting the "stimulus duration to 10ms below the expected total duration..." to obtain the most accurate (that is, consistent) individual event durations for EVENT timing mode. I assume that this "rule of thumb" should only apply to EVENT timing (thought maybe I'm wrong). I'm more unsure about what to do when combining the two timing modes. Do you ignore this "rule of thumb" even when using only EVENT timing, FrankBank, or have I just confused you (and maybe everyone else) by interjecting an EVENT timing issue into this discussion of CUMULATIVE timing; if the latter, I apologize.  Regardless, I expect David eventually will explain why my question is dumb and the answer is simple. I admit that I have done nothing, so far, to test combinations of event and cumulative durations and timings within a trial.

[Scott]

PPS - I just downloaded the most recent E-Prime 2 documentation and discovered that its critical timing chapter is much different. Please note that I have NOT yet upgraded to the E-Prime 2.0 Production Release; I'm still using E-Prime 2.0 Professional Release Candidate Build 2.0.8.90a to avoid potential compatibility problems with programs our lab is current running, at least until I become more familiar with the changes. Obviously, some of the documentation has changed. The page numbers and quotes I posted are not applicable to the most recent user's guide. I cannot find any reference to the "rule of thumb" I quoted from a previous user's guide. Nevertheless, page 94 of this new guide, in the "Further information column" does mention and provide the following link:

KB 3025 INFO: Fast/Single
Refresh Presentation in
E-Prime

This Knowledge Base article still refers to the same suggestion (which I've underlined) as before, under Important Points:

As stated in the Critical Timing chapter, the general rule of thumb when working with critical timing is to subtract 10 ms from the intended duration to account for delays that result from waiting for the next vertical blank (the beginning of the refresh cycle). This, alone, may help you minimize the OnsetDelays in your experiment.

When I search the new user's guide for "rule of thumb", I don't find anything. Maybe some feature in the Production Release makes this unnecessary or even bad advice. -- I'm really not sure. Nevertheless, I have found that following this rule can help minimize missed vertical blanks and the occasional extra refresh cycle for E-Prime version 2.0.8.90a, as well as for E-Prime 1.2, even for display durations longer than 1 or 2 refresh cycles. Obviously I need to carefully read the latest documentation and learn more about the new Production Release, and test it, before I say anything more about using E-Prime, much less start using the Production Release for my own experiments. I'm sorry for the confusion. Perhaps this has been discussed before on this forum. I admit I don't carefully read every post on this form, nor have I searched for other posting about this (possibly outdated)  "rule of thumb". I will do that asap, to find what I might have missed about this topic.

[Scott]

OK -- Here's some clarification and correction:

3027 - FEATURE: RefreshAlignment locks into nearest refresh vertical blank to promote timing accuracy

It's something I missed that evidently was introduced even BEFORE the production release, since this KB article seemed to have been originally posted 1/5/2007 9:25:00 PM (GMT,) but subsequently updated 1/4/2012 4:10:00 PM (GMT). I don't see any extended discussions of this change, or exactly when it occurred, from a quick search of this forum for RefreshAlignment. However, your analysis,

FrankBank, appears to be correct regarding the consequences of RefreshAlignment when strictly applying the quoted "rule of thumb" . This feature change may have occurred when E-Prime 2 was first introduced and I overlooked it and the potential consequences of continuing to use a 'rule' I learned for E-Prime 1.  Again, I apologize for my confusion, and for interjecting confusion into this forum. I'm not sorry to discover my error, however, and to learn things about E-Prime that I need to research more thoroughly. Thanks!

[FrankBank]

 Hi Scott, I'm going to have to think about some of the issues that you've brought up to get a better handle on them myself.  In short though, please disregard everything I said previously, as I think you are much more likely to know what your talking about than I am at this point.  I apologize for confusing you further, since you are 100% right about the 10ms advice in chapter 3, and for some reason I completely forgot about that.  I was working from memory, and I believe I was recalling the equation on page 90 (?) I think.  What that percentage is referring to I really have no idea now.

I do want to thank you though for bringing the 10ms issue to my attention.  I'll have to play around with that further on eprime since I have generally used exact refresh cycle times and gotten millisecond accuracy almost always, but I usually run on a single computer so can see how using multiple terminals with slightly varying refresh cycles could make the 10ms option an important choice.

I'll post again after I've had time to reread chapter 3.  Thanks again Scott and I apologize for making you question your setup.

[David McFarlane]

Please do the following exercise: Start with a new program. Put the
following three E-Objects in a Procedure:

- TextDisplay1: "A", Duration = 1000, Data Logging = Time Audit
- InLine1: Sleep 1000
- TextDisplay2: "B", Duration = 1000, Data Logging = Time Audit,
Timing Mode = Cumulative

Run this and observe the outcome. How long does the "A" appear on
the screen? How long does the "B" appear? Look at the results in
the .edat file. How long were the OnsetDelays? How does all that
compare with the prescribed durations of the stimuli and Sleep? What
would happen if you changed the prescribed durations? Test your
ideas by running again with different durations for the stimuli &
Sleep. What do you conclude about what appears on the screen during
the OnsetDelay of a stimulus object using Cumulative timing
mode? Does it seem that the screen simply keeps showing whatever it
already showed during this time?

-- David McFarlane

[Scott]

Hi Frank,
Which version of E-Prime are you using? If you use E-Prime 2, and haven't seen it yet, I suggest you download the new (to me) E-Prime 2.0 Documentation. Especially check the User's Guide (24MB). It's critical timing guide is Chapter 4, and I don't think that you will find anything there like that 10ms rule of thumb. Also see my reference in a previous post to RefreshAlignment, which may significantly change things. (I've been unable to find this term, RefreshAlignment,  by searching any of the documentation available under the Help menu of E-Prime 2.0.8.90a, which I'm using now.) As I explained, I don't know enough yet about this feature, exactly when it was introduced or how it's applied, to know what it all means. I think that PST's inconsistent, unreliable, and often untimely documentation has helped confuse us both. The truth may be out there, but I haven't found it yet., so I'll say no more, for now.

[David McFarlane]

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

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

[David McFarlane]

Ignore the "created" & "updated" dates on PST KB articles, they
sometimes draft those for internal documentation years before they
implement the feature, and then take more time to release the
implemented feature to the public. KB articles often include a note
on which versions they apply to, but that is missing from this
article. If you want to make a fuss about it, add an End User
Comment to the article.

Anyway, this feature was introduced with either 2.0.10.182 or
2.0.10.242. With care, this feature may automate the "rule of thumb"
insofar as it automatically advances the effective TargetOnsetTimes
by a proportion that you specify. But you still have to think
through what stimulus Durations to prescribe in order to get your
desired durations, and what actual durations will result from any
prescribed stimulus Duration. And then make sure to log needed time
audit measures, and inspect those; better yet, test everything with a
photodector & oscilloscope.

Finally, if PST documented this anywhere outside of the KB, then it
would be in the New Features Guide that comes with the latest
E-Prime. Take a look there, I have not looked thoroughly at that myself yet.

-- David McFarlane

At 11/11/2012 07:04 PM Sunday, Scott wrote:
>OK -- Here's some clarification and correction:
>
>

><http://www.pstnet.com/support/kb.asp?TopicID=3027>3027 - FEATURE:

>RefreshAlignment locks into nearest refresh vertical blank to
>promote timing accuracy
>
>
>
>It's something I missed that evidently was introduced even BEFORE
>the production release, since this KB article seemed to have been
>originally posted 1/5/2007 9:25:00 PM (GMT,) but subsequently
>updated 1/4/2012 4:10:00 PM (GMT). I don't see any extended
>discussions of this change, or exactly when it occurred, from a
>quick search of this forum for RefreshAlignment. However, your analysis,
>FrankBank, appears to be correct regarding the consequences of
>RefreshAlignment when strictly applying the quoted "rule of thumb" .
>This feature change may have occurred when E-Prime 2 was first
>introduced and I overlooked it and the potential consequences of
>continuing to use a 'rule' I learned for E-Prime 1. Again, I
>apologize for my confusion, and for interjecting confusion into this
>forum. I'm not sorry to discover my error, however, and to learn
>things about E-Prime that I need to research more thoroughly. Thanks!
>
>On Sunday, November 11, 2012 5:10:42 PM UTC-6, Scott wrote:
>PPS - I just downloaded the most recent E-Prime 2 documentation and
>discovered that its critical timing chapter is much different.
>Please note that I have NOT yet upgraded to the

><http://www.pstnet.com/support/download.asp?Type=e-prime_2_0>E-Prime

>2.0 Production Release; I'm still using E-Prime 2.0 Professional
>Release Candidate Build 2.0.8.90a to avoid potential compatibility
>problems with programs our lab is current running, at least until I
>become more familiar with the changes. Obviously, some of the
>documentation has changed. The page numbers and quotes I posted are
>not applicable to the most recent user's guide. I cannot find any
>reference to the "rule of thumb" I quoted from a previous user's
>guide. Nevertheless, page 94 of this new guide, in the "Further
>information column" does mention and provide the following link:

><http://www.pstnet.com/support/kb.asp?TopicID=3025>KB 3025 INFO: Fast/Single

[David McFarlane]

Well, I just flipped through the New Features Guide, and indeed this
feature is covered there on p. 15, section 3.4, and I think that
makes it clearer than does the KB article. I suppose it pays to read
what documentation PST actually does provide with the product :).

-- David McFarlane