Mastering E-Prime: Meaning of all time audit measures.
Scott
saultsj at missouri.edu
Sat Feb 23 05:16:16 UTC 2013
Sorry -- After reviewing the revised task from support, I see Task Events
CAN (apparently) send an onset code AND rest the port after 10 ms (or
whatever). What this support example failed to do (and what I'd hoped Task
Events could do) is replace inline code used to send conditional response
codes. Otherwise, Task Events does seem able to send any specific code,
that's available as an attribute. But even this ability seems less flexible
than how I can select from several attributes specific ones as
onsetSignalData for different objects at the beginning of each trial.
However, this sample from support might not take advantage of all options
for Task Events, so I should study the documentation more before dismissing
it. I admit I haven't give Task Events a fair chance, after being
disappointed about it's (apparent) limitations for sending conditional
response codes.
On Friday, February 22, 2013 10:06:36 PM UTC-6, Scott wrote:
>
> Thanks for warning us, David. I've used OnsetSignal for years, assuming it
> worked as advertised (after checking critical OTO intervals during test
> runs by comparing triggers in CNT files with corresponding onsets times in
> Edat files). I'm also surprised to hear that Task Events supplant using
> OnsetSignal. When I asked, Eprime support was not able to demonstrate how
> Task Events could replicate what I'm accustomed to doing with OnsetSignal,
> to code and distinguish stimuli in EEG recordings. If Task Events can
> really do the same things better, then I should reconsider my methods (of
> programming and Epoching) and adapt to using Task Events instead, now that
> I've finally adopted the Production Resease. I've been slow and cautious
> to change, and only recently started programming new experiments with
> E-Prime 2.0.10.262.. -- Scott
>
> On Thursday, February 21, 2013 5:05:34 PM UTC-6, McFarlane, David wrote:
>>
>> Justine,
>>
>> I should mention that using OnsetSignal... still entails some
>> "gotchas" (which I go over in the course).
>>
>> -- David McFarlane
>>
>>
>> At 2/21/2013 05:56 PM Thursday, David McFarlane wrote:
>> >Justine,
>> >
>> >No programming system can exactly control the actual onset time of
>> >stimuli, due to the nature and limitations of stimulus
>> >hardware. For visual stimuli in particular, the video frame rate
>> >plays one limiting role -- please see the "Critical Timing" chapter
>> >in the User's Guide that came with E-Prime (and/or take my online
>> >video course, see link below).
>> >
>> >If one wished merely to *know* when a visual stimulus got presented
>> >(as distinct from *controlling* its onset time), one might use the
>> >output of a high-speed photodector aimed at a choice spot on the
>> >display. Technically speaking, even then the time of stimulus
>> >presentation to the subject depends on things such as the distance
>> >from the display to the subject, the speed of light, photoreceptor
>> >response rates, nerve conduction to visual cortex, etc. So the real
>> >question becomes, just how accurately do you need to control or know
>> >the onset time, and can we make it "good enough"?
>> >
>> >And here we have some hope. If you synchronize your visual stimuli
>> >to start with the "vertical blank", then stimulus OnsetTime should
>> >correspond very closely to when the system starts writing the
>> >stimulus screen to the top of the display -- and starting with
>> >EP2.0.10.182, you can even adjust this (see
>> >http://www.pstnet.com/support/kb.asp?TopicID=3027 ). Now you just
>> >need to synchronize your EEG signals with the OnsetTime of your
>> >stimulus. As you have no doubt figured out, you will be hard
>> >pressed to do that using WritePort. But OnsetSignalEnabled, etc.,
>> >do just what you need here (please see
>> >"RteRunnableInputObject.OnsetSignalEnabled" and related topics in
>> >the E-Basic Help facility). And with EP2.0.10.182 and later you may
>> >accomplish the same end with the new Task Events feature, which
>> >should supplant OnsetSignal..., etc. (I show how to use
>> >OnsetSignal... to output EEG signals in my online video course, and
>> >hope to include coverage of Task Events in the future.)
>> >
>> >Finally, if you want to verify that your EEG triggers really are
>> >synchronized with your stimuli, then you should use an oscilloscope
>> >to monitor both the stimulus onset and the EEG trigger (the Black
>> >Box ToolKit may may this easier).
>> >
>> >I hope that helps.
>> >
>> >-----
>> >David McFarlane
>> >E-Prime training
>> >online: http://psychology.msu.edu/Workshops_Courses/eprime.aspx
>> >Twitter: @EPrimeMaster (https://twitter.com/EPrimeMaster)
>> >
>> >
>> >At 2/15/2013 01:47 PM Friday, justine wrote:
>> >>I am in the process of conducting my own timing tests (for an
>> >>Eprime/NetStation experiment), and this was invaluable in trying to
>> >>understand the time audit measures. I gather from this that there
>> >>is no way of knowing when the stimulus was *actually* presented on
>> >>the screen (given the refresh rate). I assume this means that my
>> >>triggers in the EEG record could be off by whatever that screen
>> >>refresh delay was. Is that correct?
>> >>
>> >>Thanks,
>> >>
>> >>Justine VanDyke
>> >>Postdoctoral Research Fellow
>> >>University of South Carolina
>> >>
>> >>On Friday, 10 September 2010 09:46:03 UTC-4, 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+u... at googlegroups.com.
>> >To post to this group, send email to e-p... 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 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.
To view this discussion on the web visit https://groups.google.com/d/msg/e-prime/-/fVeIqgS6-b4J.
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/20130222/df9ce931/attachment.htm>
More information about the Eprime
mailing list