Simple cumulative timing question

Tue Nov 13 18:12:26 UTC 2012

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
>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.
>
>On Sunday, November 11, 2012 3:04:27 PM UTC-6, Scott wrote:
>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.
>
>On Sunday, November 11, 2012 1:35:52 PM UTC-6, Scott wrote:
>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.
>
>On Saturday, November 10, 2012 6:00:46 PM UTC-6, FrankBank wrote:
>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.

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