Simple cumulative timing question
Scott
saultsj at missouri.edu
Mon Nov 12 00:04:19 UTC 2012
OK -- Here's some clarification and correction:
3027 - FEATURE: <http://www.pstnet.com/support/kb.asp?TopicID=3027>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 interjectingconfusion 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 *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/-/_ASpWzVmOm4J.
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/047a93ab/attachment.htm>
More information about the Eprime
mailing list