This article applies to:
What is Onset Delay
In E-Prime, one of the most common difficulties that researchers run into when creating experiments is the problem of Onset Delay. Onset Delay in E-Prime is defined as “the difference between when an object was scheduled to perform its critical action and when it actually did” and represents delay time in your experiment. The OnsetDelay property in an experiment is therefore detrimental to any researcher hoping to maintain millisecond accuracy in his or her experiment as it represents additional time that was, up until that point, unaccounted for. In strictly behavioral tasks, the presence of any Onset Delay is not usually enough to interfere with the actual collection of data. However, for EEG or fMRI users, the presence of Onset Delay can be ultimately detrimental to the overall timing of your trials and of the task itself.
Onset delay, in E-Prime is measured in milliseconds and, as previously stated, represents the difference between when an object was scheduled to appear in E-Prime and when it actually appeared. Note that this does not take into account any latency produced by your hardware. Data logging for this property can be toggled on and off through the Data Logging tab of any E-Object in E-Studio. This is also logged as a part of the “Standard” and “Time Audit Only”. Once you have enabled your E-Prime experiment to log Onset Delay, this can be found in your data file (.edat, .edat2 or .edat3) associated with the object on which that property was set. For example, if you turned on Standard data logging for a Slide object in your experiment called “Stimulus”, the Onset Delay for Stimulus will be under a column in your data file called “Stimulus.OnsetDelay”.
It is important to note that Onset Delay values do not impact the Reaction Time values that you get for any given response to an object. It is a common misconception that the Reaction Time (RT) values for an object should be adjusted to account for any Onset Delay found for the object. This is not true. E-Prime does not calculate the Onset Time (when the object began) until after any Onset Delay that would have happened in an object. The RT value is simply a calculation of the difference between Onset Time (taken after Onset Delay) and the exact time E-Prime registered a response from the individual. Therefore, Onset Delay is already taken into account when determining RT values and should not be adjusted for.
What Causes Onset Delay
Before you can successfully remove Onset Delay from your experiment, it is important to understand from where it is coming. In an ideal world, E-Prime can process all responses and draw to the screen as quickly as it tells the computer to do so. However, every computer will experience some delay due to hardware. This is due to the physical limitation of your computer and hardware. Probably the most important limiting factor that impacts Onset Delay is the refresh rate of your monitor.
The refresh rate of your monitor is determined by how quickly the display you are using can draw objects to it. These are usually calculated in Hertz. One of the most common refresh rates on the market is a 60Hz refresh rate. While this number is descriptive, the most important part of this number is what it looks like in milliseconds. A 60Hz refresh rate means that the screen can be updated once every 16.66666ms. This is very important to keep in mind when programming your experiment. Every computer has a different range of refresh rates available. Therefore, it is important to know the refresh rate for your monitor. That way you know how quickly your monitor can draw to the screen and circumvent the biggest causes of Onset Delay in E-Prime. Note that this does not account for any latency in the monitor itself.
In addition to the monitor, you should also keep all experiments and resources (e.g. videos, sound files, etc.) on the fastest drive available (i.e. not a network drive, cloud storage, flash drive, etc.). Using a faster drive (e.g. SSD or faster HD) can help lower Onset Delay.
How E-Prime handles Onset Delay
By default, E-Prime will be set to Event Timing Mode. In this mode, Onset Delay does not affect the Duration specified. If you must run consistently timed trials, you may take advantage of Cumulative Timing. In Cumulative Timing Mode, Onset Delay is subtracted from the object’s duration.
Steps for Reducing Onset Delay: Display
As previously mentioned, a big factor in Onset Delay is the computer’s refresh rate. Below is a list of suggestions for removing any delay caused simply by your computer’s ability to draw to the screen.
1) Duration Divisible by Refresh Rate
Once you determine how quickly your computer can draw to the screen (its refresh rate) you should then plan accordingly with the Duration of each E-Object in your experiment. For example, if you know that your monitor is capable of outputting 100Hz, this means that E-Prime can draw to the screen once every 10ms. With that in mind, it is important to ensure that your E-Objects are divisible by 10ms. If you have an E-Object that is, for example set to 501ms, E-Prime will have to wait an extra 9ms in order to draw the object to the screen. This will give you an Onset Delay value of at least 9ms simply because of the value of the Duration property. Note that if you are terminating the object via an Input Mask, you will most likely terminate during a refresh causing minor OnsetDelays.
2) Refresh Alignment > 25%
This property can be found by double clicking on the Experiment object in your experiment’s Structure window, clicking on the Devices tab and then double clicking on your Display device. The purpose of this property is to make E-Prime actively determine how much of the object’s Duration can be sacrificed in order to display the image onto a previous screen refresh instead of waiting for a longer one. Using the example in 1a, if you had an object that had a duration of 501ms and a 100Hz monitor, with Refresh Alignment set to 0%, E-Prime would wait 9ms to draw to the screen. However, if Refresh Alignment is set to anything over 25%, E-Prime will determine that is faster to draw to the screen on the previous refresh rate instead of waiting for the next one. This means that instead of 9ms Onset Delay, you will get -1. This results in much better timing for the object since it was drawn to the screen 1ms sooner than it was scheduled to, not 9ms later.
Steps for Reducing Onset Delay: Structure
1) PreRelease = (same as duration)
One of the most important properties in regard to experiment timing is the PreRelease property. This can be found on the Duration/Input tab of any object’s Properties Pages. The purpose of PreRelease is to release some of the internal processing on a single object to load the next object in the procedural timeline. Thus, reducing the amount of time required to display the object. As a note, PreRelease does not stop the displayed portion of the object or will it ever cause an object to leave the screen before its specified Duration. It will, however impact the processing of any object after it in the procedural timeline. As a rule, it is not advised to put any amount of PreRelease on an object that precedes an InLine object. However, for most other cases, setting PreRelease to (SameAsDuration) is strongly recommended to reduce Onset Delay.
2) Reusing E-Objects
Each new E-Object that E-Prime loads into its memory takes a marked amount of time to process before it can be run. E-Prime loading new E-Objects into is memory takes more time than for E-Prime to re-display an already loaded E-Object. With that in mind, it is advised that instead of creating two identical E-Objects (or two E-Objects that serve the same purpose), simply reference the same E-Object in two locations. This is as easy as dragging and dropping the E-Object from a previous procedure onto the current one while designing the experiment. Please note, if you would like multiple instances of the same E-Object in the same Procedure, you will have to drag and drop it from E-Studio’s Browser window.
3) Deleting Unreferenced E-Objects
The Unreferenced E-Objects section of every experiment is best thought of as E-Prime’s “Recycle Bin”. This is where objects are kept that are not currently referenced by any context of the experiment. While it is possible (and even advised in some experimental designs) to have objects in the Unreferenced E-Objects section of the experiment that will be loaded into the experimental context later, most experiments do not follow this design. Most experiments contain objects in the Unreferenced E-Objects section that are simply left over from design time. While they are not referenced in your experiment and, in most cases not even run, E-Prime still takes the time to load them into memory in case they are used later. Because E-Prime devotes resources (and ultimately time) to loading these Unreferenced E-Objects, it is best to ensure that any unnecessary E-Objects are purged from the Unreferenced E-Objects section.
Steps for Reducing Onset Delay: InLine Script
1) Removing Debug.Print Statements
It is a widely held misconception that InLine script is “timing independent”. This is, of course, false. While not able to directly report its timing, any command, routine or process called in InLine script takes a marked amount of time to complete. One of the most timing-heavy of these commands is the Debug.Print statement. While they are very helpful for debugging and troubleshooting script during the experiment design process, it is strongly advised that they be removed during the actual run of your experiment. Since InLine objects do not report their own timing data, the time these commands take to execute appear as Onset Delay for the next object in the procedural timeline. Therefore, they are important to remove when running the experiment.
2) Logging Loop Durations
Like the Debug.Print statements, Loops may also take a considerable amount of time to complete. However, unlike the Debug.Print statements, Loops may be essential to your experiment’s function. If this is the case, it is not a matter of removing the Loop from your experiment, it is a matter of logging how long the Loop took to run. That way, you can determine if the Onset Delay in your experiment is coming from the processing of a Loop object.