Simple cumulative timing question

Tue Nov 13 19:41:40 UTC 2012

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

At 11/13/2012 01:12 PM Tuesday, David McFarlane wrote:
>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.