This article applies to:
E-Prime 3.0
E-Prime 2.0
This item was introduced in E-Prime 2.0 (2.0.10.174).
Detail
E-Prime offers the ability to log OnsetToOnset times. This applies to objects that are visual in nature (i.e., excludes SoundOut, Wait, etc.). The OnsetToOnset time can give a close representation to the "on screen" time.
Factors that alter the OnsetToOnset time from being the actual on screen time include the use of CRT/LCD monitors and if the second display painted in an area that did not completely cover the first stimuli, thus allowing it to remain on screen.
End User Legacy Comments:
| David McFarlane 3/14/2014 6:25:00 PM |
This is a great feature and we are making use of it. Along the way we also learned (the hard way) of some behavior of OnsetToOnsetTime that I could not find documented elsewhere, so I am submitting it here. Ordinarily (and for visual objects only, see main article), OnsetToOnsetTime for stimulus stim[i]is calculated as stim[i].OnsetToOnsetTime = stim[i+1].OnsetTime - stim[i].OnsetTime. But OnsetToOnsetTime will show 0 under either of the following two conditions: - The stimulus object is the last object run in the Procedure. OnsetToOnsetTime applies only between objects run in the same Procedure, and does not cross Procedure bounds. Thus, the last object run in a Procedure has no object run after it within the Procedure, so no following OnsetTime to use for the calculation of its OnsetToOnsetTime. (In particular, what should happen for the last object run for the session?) - A response from the subject terminates the stimulus object. In principle, OnsetToOnsetTime could be calculated here (subject to constraint above), but would serve little purpose because it largely just reflects the subject RT (plus the delay from the response to onset of the next stimulus object). Subject RT, and OnsetDelay of the next object, have more meaning in this case. In retrospect this behavior seems reasonable, but it caused some distress to a user until we puzzled it out. I made a small program to demonstrate this, glad to contribute that if we can find a way. |
| David McFarlane 3/17/2014 7:57:00 PM |
It occurred to me that getting 0 for OnsetToOnsetTime of the last object in a Procedure is just an accident of when logging and object resetting take place. So I revised my demo program to disable ResetLoggingProperties for my stimulus objects, and added Inline code to log the previous value of OnsetToOnsetTime at the start of the Procedure. I still got 0 for OnsetToOnsetTime from the last object of the previous Procedure, so it seems that the OnsetToOnsetTime computation really will not cross a Procedure boundary (thinking through how I would engineer this feature, the OnsetToOnsetTime mechanism by its very design should cross the Procedure boundary, so I suppose PST programmers must have gone through some extra programming in order to disallow this). I then thought that this behavior might result from the calls to .EndOfProcedure that occur automatically at the close of each Procedure. The inability to directly edit the generated .ebs code made it hard to disable those lines so as to test this hypothesis, but I got around that by some judicious copy & paste from the generated code in order to replace the object references in the Structure with inline code. I got the same results as before, so it seems that PST has built this behavior into the OnsetToOnsetTime operation itself. |
| David McFarlane 3/17/2014 8:31:00 PM |
Um, scratch what I just said (this stuff is tricky!). OnsetToOnsetTime computation *will* cross a Procedure boundary -- I just had to move my inline *after* the first stimulus object of the following Procedure, of course (this in fact corresponds exactly to my understanding of the underlying mechanism used by PST)! So an enterprising E-Prime programmer may log the OnsetToOnsetTime of the last object in a Procedure (let's call it StimX) by observing the following rules: - StimX cannot also be the next object to run (i.e., it cannot also run first in the next Procedure that runs -- think it through!). - StimX must have its ResetLoggingProperties disabled. - Inline code to log StimX.OnsetToOnsetTime (probably to something other than StimX.OnsetToOnsetTime) must occur *after* the first stimulus object in the next Procedure to run (so that the OnsetTime of that object may participate in the calculation). Note that the logged value will then appear in the .edat file on the line *following* the trial in which StimX ran. Thus I suspect PST would (rightly) discourage logging OnsetToOnsetTime in this way, as it would almost certainly result in confusion and mistakes. |
| David McFarlane 3/18/2014 3:22:00 PM |
So, here is my attempt at a definitive statement about this behavior... OnsetTimeToOnsetTime applies only between visual stimulus objects (as documented in the main article), and for stimulus stim[i]is ordinarily calculated as stim[i].OnsetToOnsetTime = stim[i+1].OnsetTime - stim[i].OnsetTime. But the logged OnsetToOnsetTime will show 0 under either of the following two conditions: - OnsetToOnsetTime gets logged before the next stimulus object runs and completes the computation. This typically happens when the stimulus object is the last object run in the Procedure (although an enterprising programmer may work around this, see earlier comment). - A response from the subject terminates the stimulus object. In principle, OnsetToOnsetTime could be calculated and logged here (subject to constraint above), but would serve little purpose because it largely just reflects the subject RT (plus the delay from the response to onset of the next stimulus object). Subject RT, and OnsetDelay of the next object, have more meaning in this case. |
| Brandon Cernicky 3/18/2014 4:38:00 PM |
The intent of the OnsetToOnsetTime property/logging was to provide a way for the request we received in support for "how long was my stimulus on screen". Since too many false data points could happen with a screen time calculation (position of stimulus, monitor type, etc) the OnsetToOnsetTime property was introduced. As David describes, there are scenarios where this property will result in a value of zero or a logging value of zero. This is done to avoid the confusion of logging data from a previous/next trial. For the special cases that David mentions such as needing the OnsetToOnsetTime for objects that collected and terminated as result of a response or carry over into the next trial, techniques as David describes or other script based solutions can be used to achieve the per paradigm result. |
Comments
0 comments
Please sign in to leave a comment.