Mastering E-Prime: Meaning of all time audit measures.
David McFarlane
mcfarla9 at msu.edu
Mon Feb 25 21:01:52 UTC 2013
Sylvain,
Yes, as far as I understand, OnsetSignal should coincide with
OnsetTime -- in fact, a Knowledge Base article says just that
(http://www.pstnet.com/support/kb.asp?TopicID=1318 ). But you should
not take anyone's word for that, not even mine (and certainly not
PST's). You should test that for yourself with an oscilloscope or a
Black Box ToolKit. Or if you want to have E-Prime test itself, and
you have a parallel port that will both output and input data, you
may try the following hack: Set up a PortDevice at the parallel
port, and use OnsetSignal with the same parallel port. Then get the
timestamp of OnsetSignal from the History of the PortDevice (no, you
do not need an input mask, and yes, this is advanced E-Prime
hacking), and see if that matches OnsetTime. I have used this hack
myself to explore E-Prime's input mechanisms, but have not used this
to explore OnsetSignal, and I did that hack with E-Prime 1.2 and an
older laptop so don't know if the hack still works on later
systems. Finally, if you have EP2.0.10.x or later (Pro only), then
you should explore using Task Events instead of OnsetSignal, etc.
That said, two comments on your code example:
1) Because your SignalData never changes, yes, you could put that
code at the top the Procedure, or better yet, at the top of
SessionProc (that is what I would do) -- it only needs to run once
for the entire session, no need re-running it each time before the
stimulus. But I understand it may make the program easier to read by
putting this action before the stimulus, and that has some value (so
when I put OnsetSignal code up in SessionProc, down in the Procedure
I still add an InLine just with comments to explain what I did).
2) Should your line
StimEEG.OffsetSignalData = 50
read instead
StimEEG.OffsetSignalData = 0
? I.e., don't you want to use OffsetSignal to reset the signal so
that the OnsetSignal will work the next time around?
Regards,
-----
David McFarlane
E-Prime training
online: http://psychology.msu.edu/Workshops_Courses/eprime.aspx
Twitter: @EPrimeMaster (https://twitter.com/EPrimeMaster)
At 2/24/2013 09:49 AM Sunday, Sylvain wrote:
>David and Scott,
>
>Thank you for your answers. I need to be reassured. When doing EEG
>experiment, I always run an inline before the object I want to
>trigger(maybe I could even do that at the top of the procedure I
>guess). Let's call this object StimEEGa,d the trigger 50.
>What I always did was an inline like:
>
>StimEEG.OnsetSignalEnabled = True
>StimEEG.OnsetSignalPort = &H378
>StimEEG.OnsetSignalData = 50
>
>StimEEG.OffsetSignalEnabled = True
>StimEEG.OffsetSignalPort = &H378
>StimEEG.OffsetSignalData = 50
>
>If I understand correctly This inline tell "wait for the object
>StimEEG to run and send the signal'. By running I mean waiting for
>StimEEG to be drawn on the screen right, independantly of any
>pre-release ? On the e-prime side, does this correspond to StimEEG.OnsetTime?
>
>Thank you,
>
>Sylvain
>
>On Friday, February 22, 2013 6:42:29 PM UTC+1, McFarlane, David wrote:
>Sylvain,
>
>At 2/22/2013 06:36 AM Friday, Sylvain wrote:
> >Hi David,
> >
> >I have a question regarding to pre-release and timing.
> >
> >I did a little experiment trying to get the timestamp of the onset
> >of stim, and the offset or it.
>
>Wonderful, everyone should do these sorts of explorations (that's how
>I figured out all this stuff).
>
>
> >It's simple basically i have :
> >
> >- Inline1: I collect t1 = Clock.ReadMillisec
> >- Then an ImageDiplay for 200 ms with a pre-realase equal to the
> >duration of it. I log the onset of ImageDiplay and the offset of it;
> >- Inline 2: I collect t2 = Clock.ReadMillisec
> >
> >Doing that, basically I get t2-t1 almost equal to 0 modulo some
> refresh rates.
> >I also get ImageDiplay.OnsetTime = ImageDiplay.OffsetTime.
>
>As you should. You might find OffsetTime slightly behind OnsetTime;
>and under these conditions (PreRelease = Duration), you should find
>that TargetOffsetTime = TargetOnsetTime without exception.
>
>
> >1) There's something there that I don't really understand, which
> >timestamp should I really consider, ImageDiplay.OnsetTime or
> >ImageDiplay.OffsetTime?
>
>That depends entirely on what you wish to do with that timestamp.
>
>
> >2) If I understood pre-realase affect offset time, so does that mean that:
> >ImageDiplay.Duration = (ImageDiplay.OffsetTime
> >- ImageDiplay.OnsetTime) + pre-realase
>
>Not quite -- E-Prime can control only *Target* offset (& onset)
>times, not actual times. Actual offset (& onset) times are subject
>to the limitations of the stimulus presentation hardware. Also, I
>would not write the relationship that way -- that makes it sound like
>Duration derives from the other quantities, which is wrong. As I
>described earlier, Duration remains whatever you asked it to be, so
>should appear only on the right side of the equals sign as it is used
>to determine other quantities. Thus, repeating what I wrote in my
>earlier description of TargetOffsetTime, in the case of Event timing mode,
>
> ImageDisplay.TargetOffsetTime = ImageDisplay.OnsetTime +
> ImageDisplay.Duration - ImageDisplay.PreRelease
>
>Note that, in the case PreRelease = Duration (the new default setting
>since EP2.0.10.x), we get simply
>
> ImageDisplay.TargetOffsetTime = ImageDisplay.OnsetTime
>
>which fits your observations. If instead we set PreRelease to 0, we find
>
> ImageDisplay.TargetOffsetTime = ImageDisplay.OnsetTime +
> ImageDisplay.Duration
>
>which perhaps is what you expected (and was the default for Event
>timing mode prior to EP2.0.10.x).
>
>And just to drive the point further, OffsetTime does *not* indicate
>the time at which *presentation* of a stimulus ends. Rather, (for
>most practical purposes) it indicates when *execution* of the
>stimulus Run method ends (strictly speaking, this describes
>FinishTime, see my earlier description for the fine distinction
>between OffsetTime and FinishTime).
>
>Furthermore, even with PreRelease set to 0, neither Duration nor
>(OffsetTime - OnsetTime) necessarily indicate the actual duration of
>the stimulus. In particular, a visual stimulus does not disappear at
>its OffsetTime (ignoring Clear After, which has been deprecated), but
>remains visible until replaced by another visual stimulus, so actual
>presentation duration is
>
> Stim2.OnsetTime - Stim1.OnsetTime
>
>and EP2.0.10.x Pro can now log those values for you
>(<http://www.pstnet.com/support/kb.asp?TopicID=718>http://www.pstnet.com/support/kb.asp?TopicID=718
>)!
>
>
> >3) The fact that Inline2 is executed at the same time as Inline1 is
> >particulary disturbing for me. Does that mean than Inline placed
> >after an object could be executed while this object is still on screen?
>
>Yes, and that is exactly what we want it to do in many, many cases
>(e.g., to handle multiple mouse actions while a visual stimulus
>remains on the display, or to prepare the next stimulus during the
>run of the current stimulus). If you really want your InLine to wait
>until the previous object completes its Duration, then set PreRelease
>of that object to 0.
>
>Hope that helps,
>-----
>David McFarlane
>E-Prime training
>online:
><http://psychology.msu.edu/Workshops_Courses/eprime.aspx>http://psychology.msu.edu/Workshops_Courses/eprime.aspx
>
>Twitter: @EPrimeMaster
>(<https://twitter.com/EPrimeMaster>https://twitter.com/EPrimeMaster)
>
>
> >Thank you for any answer, I'm confused about this!
> >
> >Sylvain
> >
> >On Friday, September 10, 2010 3:46:03 PM UTC+2, David McFarlane wrote:
> >When you look at the Logging tab on the properties page of any
> >stimulus object, you will find a host of items available for
> >logging. Most of these are time audit data. But what do all these
> >items mean, and what are they good for? Chapter 3 of the E-Prime
> >User's Guide discusses time auditing to some degree, and the timing
> >diagram at Appendix E provides one way to see the relationships
> >between these items. As an alternative, here I try to set out, in
> >order, a brief description of these items.
> >
> >First let us distinguish between timing control *settings* and time
> >audit *measures*. The following items do not reflect any results
> >formed during the course of a stimulus but simply log the settings
> >provided by the user (e.g., you). You may choose to have any of
> >these logged just to keep a record of settings active during the
> experiment:
> >- Duration: To reiterate, this does *not* show the actual duration of
> > the stimulus, only the setting as provided by the user.
> >- PreRelease: Affects the TargetOffsetTime (see below).
> >- TimingMode: Event, Cumulative, or Custom, as set by the user (see
> > the online E-Basic Help).
> >- CustomOffsetTime: In Custom timing mode, overrides the
> > TargetOnsetTime (see the online E-Basic Help).
> >- CustomOnsetTime: In Custom timing mode, overrides the
> > TargetOffsetTime (see the online E-Basic Help).
> >
> >Now, the raw time audit measures, listed in the order in which events
> >occur during the execution of a stimulus object. These are all time
> >stamps in milliseconds from the start of the current program run:
> >- StartTime: Time at which E-Prime started executing the stimulus
> > object.
> >- TargetOnsetTime: Scheduled time at which presentation of stimulus was
> > to begin; set automatically from GetNextTargetOnsetTime (see online
> > E-Basic Help).
> >- OnsetTime: Time when E-Prime actually submitted the stimulus data for
> > presentation (e.g., proceeded to copy data to display memory or load
> > sound buffer). This may not coincide with when the stimulus actually
> > got presented, e.g., if data are submitted in the middle of a display
> > refresh cycle then they may not get presented until the next refresh.
> >- ActionTime: According to the online E-Basic Help, time at which
> > E-Prime completed the "critical action" of the stimulus. The
> > documentation remains somewhat vague about this -- perhaps "critical
> > action" means copying data to display memory, or loading a sound or
> > video buffer. In my tests, ActionTime never lags more than 1 ms
> > behind OnsetTime, so it serves practically the same purpose as
> > OnsetTime.
> >- TargetOffsetTime: Scheduled time at which offset actions (e.g.,
> > clean-up, ClearAfter, StopAfter) of stimulus object were to begin,
> > e.g., OnsetTime + Duration - PreRelease (Event timing mode), or
> > TargetOnsetTime + Duration - PreRelease (Cumulative timing mode).
> >- OffsetTime: Time when E-Prime actually began the offset actions of
> > the object. Actions may not take practical effect until next
> > vertical blank, or until presentation of next stimulus.
> >- FinishTime: Time when E-Prime exited from execution of the
> > stimulus object and proceeded to execute the next section of the
> > program (e.g., next stimulus object or inline code). Note that
> > *execution* of a stimulus *object* may end before *presentation* of
> > the *stimulus* ends; this is the point of PreRelease (as well as
> > happening as a matter of course with some stimuli such as some
> > sounds).
> >
> >Finally, a few composite time audit measures derived from the raw
> >measures above and provided for convenience:
> >- OnsetDelay = OnsetTime - TargetOnsetTime
> >- ActionDelay = ActionTime - OnsetTime
> >- OffsetDelay = OffsetTime - TargetOffsetTime
> >- DurationError = OffsetTime + PreRelease - OnsetTime - Duration
> >
> >Note:
> >- Time audit measures include the ActionTime that follows upon
> > OnsetTime, but no corresponding item to follow upon OffsetTime.
> >- No time audit item for time stamp of vertical blank, although many
> > stimuli do not take full effect until just after a vertical blank.
> >
> >-- David McFarlane, Professional Faultfinder
--
You received this message because you are subscribed to the Google Groups "E-Prime" group.
To unsubscribe from this group and stop receiving emails from it, send an email to e-prime+unsubscribe at googlegroups.com.
To post to this group, send email to e-prime at googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
More information about the Eprime
mailing list