The process of preparing a visual stimulus to be displayed or a sound or movie to be played requires some preparation time. This preparation time can be significant: for visual stimuli, delays can be more than half of a refresh rate, and for auditory stimuli, delays can be in the tens of milliseconds. E-Prime’s stimulus preparation solutions are designed to reduce these delays, and/or move as much of it as possible to a non-critical interval in the trial, such as before the presentation of the key trial sequence.
In the checkerboard example that we examined at the start of this chapter, we saw that stimulus setup time for image files added about 36 ms to the median display time. To correct the problem, the next display must be setup while the participant is looking at the current display; the time-consuming reading and loading of the next image file needs to occur before it is time to present the image.
E-Prime uses the concept of using PreRelease time to address this problem. This feature allows the current stimulus to release a portion of its execution time to a following stimulus in order to allow the following stimulus to perform setup activities (e.g., read the data from disk and get the image ready in memory). Then, at the scheduled time for the following stimulus to be presented, the display is already prepared and it is simply copied to the screen. By overlapping the setup time for the following display with the duration of the current display, the delay caused by the setup time can be reduced and potentially eliminated. If the PreRelease time allotted is greater than the setup time required, the images can be loaded and presented without delay. In the checkerboard example, a PreRelease time of 50 ms would provide ample time for setup, and there would be no added variability.
E-Prime uses a default value for PreRelease, “(same as duration)”. By accepting this value, you do not need to estimate or experiment with different values of PreRelease to find the optimal value, and you provide the system with as much time as possible to prepare the next display object.
An important aspect of how PreRelease works is that the stimulus presentation and response processing occur in parallel. This means that although the next stimulus may be prepared while the current stimulus is still being presented, any responses entered prior to the actual display of the second stimulus will be scored according to the settings of the current stimulus (i.e., the response is always scored by the stimulus prompting the response). Let’s review the checkerboard example. The results from the example that was programmed in E-Prime but without properly using the timing tools showed that the average the preparation or setup time approximately 36 ms. So, after 36 ms the first stimulus was presented to the participant. When PreRelease is used, the second stimulus is selected and prepared for presentation while the first stimulus is still being presented. After 72 ms has elapsed, the second stimulus is prepared and ready to be displayed. The program then waits the remainder of the specified duration for the first stimulus (200 ms from the onset of the first display at 36 ms), and then presents the second stimulus (at time 200 ms). At this time, the third stimulus is prepared while the second stimulus is being displayed. All the stimuli would then occur with the intended 200 ms interval. The displays would occur starting at 36, 236, 436, 636 ms, etc. From the participant’s point of view, the experiment would present a stimulus every 200 ms with no apparent setup time or cumulative timing drift.
Figure 1 shows a diagrammatic representation of the timing with and without a PreRelease time specified. With PreRelease, as long as the preparation time is less than the display time, there will be no added delays. Again, using the default value of “(same as duration)” ensures that the maximum amount of time is made available to E-Prime to prepare the next display.
The proper use of PreRelease also substantially corrects for the second timing problem. What are the challenges?, that actual display durations can be significantly longer than the intended durations. Recall that Windows can arbitrarily halt the program for periods of tens and sometimes hundreds of milliseconds. If one of these operating system delays occurs during the critical sequence of “terminate the last stimulus, generate the next stimulus, and present the next stimulus,” it could potentially produce delays in what the participant sees. When PreRelease is used, E-Prime accomplishes as much work as possible, as early as possible (i.e., in some cases as soon as the first object performs its critical action, time can be released to the next object). It also prepares the display information in an off-screen bitmap so it is ready to go, and unlikely to be touched by the operating system. The code for monitoring when to display the stimulus is in a tight loop to keep execution short and keep the code in memory. If the operating system takes control and steals time that is less than the PreRelease time, the tight code segment of putting up the display will not be affected. Although the operating system can still stop the tight code loop at presentation time, the probability of such an event is greatly minimized by making the final critical actions brief.
While the PreRelease mechanism is a powerful and useful tool, there are a few caveats when using PreRelease of which you should be aware. First, PreRelease provides extra processing time for the next object in the Procedure; it does not provide any additional processing time for the object on which it is enabled. Therefore, there is typically no benefit to using PreRelease on the last object in the procedure, unless you:
- Have GeneratePreRun set to TopOfProcedure
- Are not playing a movie or audio file on the last object of the procedure (otherwise, PreRelease on this last object stops the playing of the audio file or the movie)
- Are not scoring data from responses that have a time limit set to the end of trial (this could cause data loss because the trial would end and be in the process of prepping the next trial before the response is able to be registered)
- When all of these conditions apply, then PreRelease on the last object can provide a significant benefit
Secondly, you should not specify a value of PreRelease that is greater than the object’s Duration, whichincludes the case where the object’s Duration is set to 0. Unintended timing problems may arise when PreRelease is greater than the object’s Duration. Generally, however, the default value of “Same as duration” works best is most situations, and eliminates the need for careful testing of a range of values to find the best one.
PreRelease and Input Masks
There are three potential conflicts that can arise with the default value for PreRelease. First, if an object is using PreRelease and the next object is a FeedbackDisplay, then the statistics shown to the participant during the experiment run could be inaccurate because the object that pre-released may still be accepting responses. To assist with this situation, use the FeedbackDisplay.ProcessInputObjectPendingInputMasks property. By default, this property (accessible from the General Tab on the FeedbackDisplay object) is selected, as shown in Figure 2.
When this property is selected, then the scoring script that is executed as part of the Feedback Display is not performed until all of the input masks for object have been terminated, either by timing out or from receiving the maximum number of responses.
There is a similar concern if the next object that appears after an object using PreRelease is an InLine or PackageCall. It can’t be assumed that the prior object has been cleared or is no longer collecting responses from input masks. In this case, script should be used to check the status of any pending input masks. See TIMING: PreRelease defaults changed to promote better timing accuracy .
A final concern is when the very last object on a Procedure has PreRelease. In this case, it will release into the final logging of the Procedure and select the next exemplar for the trial. The Procedure. ProcessPendingInputMasks will assist with this.
In summary, the FeedbackDisplay.ProcessInputObjectPendingInputMasks property and the Procedure. ProcessPendingInputMasks property enable users to routinely accept the default value for PreRelease (“same as duration”) without having to add special script to handle these cases. In the event that you would need to handle these cases, script such as that Sample Process Template, can be used.
The process of loading movie, image and sound files is a time-consuming one. For example, in the checkerboard experiment, the time that was required to prepare each graphics file was an average of 36 ms, and most of that preparation time involved reading the file from the hard drive and loading it into video memory.
Internally, E-Prime utilizes two separate steps to present sound, images or movies. The first step is performed by the object’s Load method, and results in the media file being read from the hard drive into memory. The second step occurs when object’s .Run method executes and results in the presentation of the media file. In E-Prime, a media file cannot be presented without first being loaded into memory, in part because reading directly from the disk is prohibitively slow.
E-Prime uses the property GeneratePreRun to determine when media files are loaded. This feature, which is available on all RteRunnableInput objects (i.e. Text, Slide, ImageDisplay, MovieDisplay, SoundOut) enables you to direct the time-consuming process of loading of a stimulus file from disk into memory to occur prior to the critical timing sequence in the trial. To do so, GeneratePreRun should be set to “TopOfProcedure”, which is the default value. With this setting, E-Run will load any sound, graphics, or movie files that are set from an attribute before the object which is presenting the media file begins to execute. More specifically, the <object>.Load method is placed in the Procedure_Start section of script, prior to the start of the object execution. This is illustrated in Figure 3 below, left hand panel.
Conversely, when GeneratePreRun is set to “BeforeObjectRun”, the <object>.Load method is placed directly before the <object>.Run call. As a result, the media file will not load until the object’s .Run method is called. In this case, the time required to load the media file is reflected in the object’s OnsetDelay.
The GeneratePostRun feature is the mirror/opposite effect, but is not currently utilized by any Toolbox objects in E-Prime. GeneratePostRun is made available for PackageCalls when necessary.
NOTE: When using the TopOfProcedure GeneratePreRun option, take care when using [attrib]references for any properties on the objects that are modified by c.SetAttrib calls on the Procedure. Doing so will successfully update the value of the attribute in the Context, via InLine objects on the Procedure but since the object has already performed its .Load operation, it will not take into account for the new value.
Stimulus Preparation Solutions
- DO use GenerateTopOfProcedure where possible to enable media files to be loaded during the non-critical timing inter-trial interval.
- DO use PreRelease same as duration except when it would be an issue.
Next Article: TIMING: Stimulus Presentation Solutions 
Previous Article: TIMING: Operating System Solutions 
Please sign in to leave a comment.