Simple cumulative timing question

[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*<http://www.pstnet.com/support/download.asp?Type=e-prime_2_0>; 
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 <http://www.pstnet.com/support/kb.asp?TopicID=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.
To view this discussion on the web visit https://groups.google.com/d/msg/e-prime/-/-Oy2JNNTl2oJ.
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/20121111/e28a6dd5/attachment.htm>