Digest for e-prime at googlegroups.com - 4 Messages in 1 Topic
Justin
nockmss at gmail.com
Mon Nov 12 11:09:55 UTC 2012
On Mon, Nov 12, 2012 at 10:53 AM, <e-prime at googlegroups.com> wrote:
> Today's Topic Summary
>
> Group: http://groups.google.com/group/e-prime/topics
>
> - Simple cumulative timing question <#13af441109236b15_group_thread_0>[4 Updates]
>
> Simple cumulative timing question<http://groups.google.com/group/e-prime/t/59a24c90b3f8b867>
>
> Scott <saultsj at missouri.edu> Nov 11 11:35AM -0800
>
> 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 <saultsj at missouri.edu> Nov 11 01:04PM -0800
>
> 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:
>
>
>
>
> Scott <saultsj at missouri.edu> Nov 11 03:10PM -0800
>
> 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:
>
>
>
>
> Scott <saultsj at missouri.edu> Nov 11 04:04PM -0800
>
> 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:
>
>
>
> You received this message because you are subscribed to the Google Group
> e-prime.
> You can post via email <e-prime at googlegroups.com>.
> To unsubscribe from this group, send<e-prime+unsubscribe at googlegroups.com>an empty message.
> For more options, visit <http://groups.google.com/group/e-prime/topics>this group.
>
> --
> 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.
>
>
>
--
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listserv.linguistlist.org/pipermail/eprime/attachments/20121112/69d8e816/attachment.htm>
More information about the Eprime
mailing list