Simple cumulative timing question

Sat Nov 10 23:27:52 UTC 2012

Hi Scott, I'm just wondering where you saw in the E-prime documentation to 
set the duration less than (rather than exactly) at some multiple of the 
refresh rate?  Maybe I'll try doing that as well.  My (perhaps faulty) 
understanding of the E-prime documentation is a little different.  I 
thought what happens when you set the duration to less than an exact 
multiple of the refresh cycle is that you end up with a percentage of your 
trials displayed at the +1 refresh cycle and -1 refresh cycle that bounds 
that chosen duration.

So, say you used 90 ms in your case.  Your upper bound refresh cycle is at 
100ms and lower is at 100-16.7 = 83.3 ms.  The distance of your chosen 
duration from these two points determines the percentage of trials that 
will be of either the lower or higher duration.  So then:
90 - 83.3 = 6.7 ms.  Then divide that by the refresh cycle: 6.7/16.7 = 
40%.  Since it is  40% of the distance between refresh cycles you'd end up 
with 40% of your trials at 100 ms and 60% at the low end of 83.3 ms.  If 
you used 95 ms instead you'd get 95 - 83.3 = 11.7 and 11.7/16.7 = 70% so 
70% of your trials would be 100 ms in duration and 30% at 83.3 ms.  That is 
how i read it anyways, would be very interested to hear others thoughts!  

On Saturday, November 10, 2012 10:58:14 AM UTC-8, Scott wrote:
>
> recently have needed to use cumulative timing for longer-term timing 
> accuracy of trial & block durations. I have related questions about  event  
> and cumulative timing, and combining them. If I have a visual stimulus what 
> I want displayed for 100 ms (6 refresh cycles at 60 hz) and use event 
> timing for this object, E-Prime documentation recommends setting the 
> duration of that object to 90 ms to minimize the chance that E-Prime will 
> miss detecting a refresh (a little more than half a fresh cycle to watch 
> for the next vertical blank). I've tested this, and on our PCs I've found 
> that it does reduce missed refreshes (though I've found subtracting 5 
> rather than 10 ms works more consistently).  If I set the visual display 
> duration to 100 ms, the onset to onset time (to the following object) will 
> occasionally be 116 ms, but that almost never happens if I set the duration 
> to 90 or 95 ms. I have the following two questions about event and 
> cumulative timings:
>
>    1. Is this adjustment (setting duration to about half a refresh less 
>    than desired target duration) generally a good practice to achieve the most 
>    consistent event timing durations for visual displays?
>    2. How does this practice need to be reconsidered when using a 
>    combination of event and cumulative timings? I've used only one or the 
>    other, and have always set duration to the exact value I want when using 
>    cumulative timing, but usually 5 ms less when using event timing (combined 
>    with onset syncs and no clear after). 
>
> -- Thanks for advice and suggestions (which I promise to test before using 
> in my experiments).
>
> On Friday, November 9, 2012 3:16:26 PM UTC-6, McFarlane, David wrote:
>>
>> Yes, the diagrams in the manuals leave much to be desired.  That's 
>> why I prefer plain math, such as I gave in my earlier reply.  Just 
>> think through the math and it should all become clear; also, run some 
>> exercises, log all the time audit measures, look at the outcome in 
>> the .edat files, and it should all make sense. 
>>
>> Basically, you surmise correctly that if stimulus S is set to 
>> Cumulative and follows an InLine that takes up some time, then 
>> stimulus S will still end (or equivalently, the stimulus following S 
>> will start) at the same time that it would have if the InLine were 
>> not there, which is just what you want.  That is one of the beauties 
>> of Cumulative timing mode.  The rest of your objects may then use 
>> Event or Cumulative timing mode, as seems most appropriate for each 
>> one.  Typically people use Cumulative on all the objects in their 
>> Procedures in order to keep synchronized with external events or 
>> equipment (e.g., fMRI volume scans), but yes if you want all your 
>> other objects to last at least their full Durations regardless of 
>> OnsetDelays, then you should keep them at Event. 
>>
>> BTW, more commonly people resort to the following sort of kludge: 
>>
>>      Const  SDuration as Long = 1000 
>>      Dim  t0 as Long 
>>      t0 = Clock.Read 
>>      ' <the rest of your InLine goes here...> 
>>      c.SetAttrib "SDuration", SDuration - (Clock.Read - t0) 
>>
>> And then use [SDuration] for the Duration of S.  I.e., they use of 
>> bunch of extra inline code to adjust the stimulus Duration on the 
>> fly.  But this is a lot of extra work, it fails to take advantage of 
>> the timing facilities already built in to E-Prime objects, and is not 
>> even as exact.  So I prefer your approach (and have done this in the 
>> past myself). 
>>
>> I stress again, please do not believe anything that you read in the 
>> manuals or here (not even from me), run your own tests and make sure 
>> that everything makes sense to you. 
>>
>> ----- 
>> David McFarlane 
>> E-Prime training 
>> online:  http://psychology.msu.edu/Workshops_Courses/eprime.aspx 
>> Twitter:  @EPrimeMaster (https://twitter.com/EPrimeMaster) 
>>
>> /---- 
>> Stock reminder:  1) I do not work for PST.  2) PST's trained staff 
>> take any and all questions at 
>> http://support.pstnet.com/e%2Dprime/support/login.asp , and they 
>> strive to respond to all requests in 24-48 hours -- this is pretty 
>> much their substitute for proper documentation, so make full use of 
>> it.  3) In addition, PST takes questions at their Facebook page 
>> (http://www.facebook.com/pages/Psychology-Software-Tools-Inc/241802160683 
>> ), and offers several instructional videos there and on their YouTube 
>> channel (http://www.youtube.com/user/PSTNET ) (no Twitter feed yet, 
>> though).  4) If you do get an answer from PST staff, please extend 
>> the courtesy of posting their reply back here for the sake of others. 
>> \---- 
>>
>>
>> At 11/9/2012 04:03 AM Friday, FrankBank wrote: 
>> >Hi David, 
>> >Thanks for your response.  I looked over the help file 
>> >(GetNextTargetOnsetTime, etc) and had a hard time understanding how it 
>> >all works.  I'll try again though and see if I can make sense of it. 
>> > 
>> >In the meantime, I am looking at figure 9 in Chapter 3 of the user's 
>> >guide (page 90) that compares event mode and cumulative mode.  The 
>> >reason I thought cumulative would be good for the first slide -only- 
>> >was because that slide is the only slide in the procedure that is 
>> >blank (a white screen).  Looking at the user's guide it isn't clear to 
>> >me what is shown on the screen during delays.  Is it the previous 
>> >slide? A blank white screen?  It doesn't seem to say so I thought it 
>> >was a blank white screen.  Therefore I thought using cumulative mode 
>> >during my blank slide would seem the best choice, since the delay + 
>> >slide time would give me a consistent blank white screen duration 
>> >(delay+ shortened slide 1 duration) across all trials. 
>> > 
>> >The rest of my slides in the procedure have stimulus presentations and 
>> >I would like to keep their durations fixed, so event timing for these 
>> >seemed the best idea.  I only seem to be getting consistent onset 
>> >delays with the first slide after the inline, so if their was some 
>> >anomalous delay for the later slides event timing would keep their 
>> >durations equivalent. 
>> > 
>> >I feel like maybe I'm missing something here, so please let me know if 
>> >that's the case. 
>> >thanks again, 
>> >Frank 
>>
>>

-- 
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/-/Zjt3KnVD1SIJ.
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/20121110/0706477f/attachment.htm>