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 
<br>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 "<b>stimulus duration to 10ms below the expected total duration...</b>" 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 <b>combining</b> the two timing modes. Do you ignore this "rule of thumb" even when using only EVENT timing, <span><span style="color: rgb(0, 104, 28);" class="GI2MSK2DPCB">FrankBank,<font color="#000000"> <span style="font-weight: normal;">or </span></font></span></span>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.<br><br>On Sunday, November 11, 2012 1:35:52 PM UTC-6, Scott wrote:<blockquote class="gmail_quote" style="margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Sorry if I wasn't sufficiently clear. This adjustment is ONLY done for <b>EVENT</b> 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 <i><b>E-Prime User’s Guide Chapter 3: Critical Timing</b></i> (page 99):<br><div style="margin-left:40px">The equation to use for determining what stimulus duration to specify in E-Prime is as follows:<br><b>Stimulus Duration to Specify = (Refresh Duration ms/cycle * Number of cycles) - 10ms</b><br></div>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). <br><br>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 <b>EVENT</b> timing (in fact they explain this for most of 2 pages of Chapter 3). Now that I have hopefully clarified what I was <b>trying</b> to say, please tell me: Has this recommendation changed? If so, someone <b>please</b> 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 <b>EVENT</b> 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.<br><br>On Saturday, November 10, 2012 6:00:46 PM UTC-6, FrankBank wrote:<blockquote class="gmail_quote" style="margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">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.<br></blockquote></blockquote>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups "E-Prime" group.<br />
To post to this group, send email to e-prime@googlegroups.com.<br />
To unsubscribe from this group, send email to e-prime+unsubscribe@googlegroups.com.<br />
To view this discussion on the web visit <a href="https://groups.google.com/d/msg/e-prime/-/nj127TnFAsEJ">https://groups.google.com/d/msg/e-prime/-/nj127TnFAsEJ</a>.<br />
For more options, visit <a href="https://groups.google.com/groups/opt_out">https://groups.google.com/groups/opt_out</a>.<br />
 <br />
 <br />