"present the same trial again" feedback timing


I am using SuperLab to run a change detection study in which a single trial consists of four events: (1) a focal point is presented (for 500 ms) followed by (2) a picture (for 750 ms) followed by (3) a focal point (for 500 ms) and finally (4) the same picture with a change (which I would like to display for only 750 ms).

I have added feedback to this last picture so that the trial will repeat if the participant does not enter a response within the time limit. However, my problem is that this last event then appears for much longer than 750 ms (even though this is the time I designated in the “input” page of the event). I have even tried to compensate by shortening the time limit of this trial, but it does not seem to make a difference.

Why is it taking so long to “cycle back” and repeat the trial? How can I fix this to that the last image is presented for the same duration as the first (i.e., 750 ms)?

Thanks so much for the help,


Hi Kayla,

By default SuperLab does not erase the screen on its own. If you create a blank text event and under the Input tab check on “Immediately after the event is presented.” Then, in feedback tab, have SuperLab present the blank text event. This will erase the screen and start the new event.

Thanks Monika T. I tried this, I believe, with no success.

So, just to be sure I correctly did what you are suggesting: First, I created a blank text event and inserted this as the first event of the trial (so the event order is now: blank text, followed by text with fixation point, image 1, text with fixation point, image 2). For the blank text event, I clicked “Immediately after the event is presented” under the Input tab, as you suggested. Then because I would like to repeat the entire trial if there is no response after the last image, image 2, I have the feedback for this image 2 event set to “provide feedback if there is no response within the event’s time limit” [what to do]=present the same trial again. And the option is to provide feedback when the event’s time limit is up (at the bottom). As I understand it, this should present the blank event which clears the screen and starts the trial again (on fixation point, image 1, text with fixation point, image 2, … and back again) but my presentation still gets stuck on the last image, where the feedback instructions are to loop back. It just pauses there for much longer than the specified time.

As an alternative, I tried inserting the blank text event as the last one of the trial, after image 2 and i changed the feedback so that now the blank fixation would loop back to the beginning of the trial (I removed this feedback from image 2), but this feedback instruction seems to conflict with the input instruction you suggested for the blank text event (to end the blank text event and immediately move to the next event) because instead of repeating the trial, SuperLab just moves onto the first event of the next trial. Please help!

still need assistance!

Can anyone help me resolve this issue? I really need to regulate the timing so that I don’t lose ms when cycling back to repeat the same trial. I need to run this experiment soon! Any help would be appreciated!

Thank you,

It’s difficult to tell for certain what’s going wrong without seeing the experiment itself. Can you post the sl4 file? I shouldn’t need the stimuli.

experiment file

Here is a sample of the experiment. I have changed the timing to 250 ms for each event (this is what I truly need). What I have loaded here is the experiment without the blank screen added as Monika suggested (because that did not seem to work, as I was inserting it, anyway).

Thank you in advance for you help!

sample.sl4 (25 KB)

Okay, this took me a little while to figure out, but I’ve narrowed it down to a couple details that should help.

  1. Tell SuperLab to load all stimuli before the experiment. The effectiveness of this depends on how many stimuli you’ll actually have, but if you have enough RAM, having your stimuli pre-loaded helps. (Experiment menu->Options->Memory Management->Load them all…) With the stimulus files I chose, this made a 60ms one-time difference the first time through the trial.

  2. –and this is the big one-- Don’t expand your images to full screen. Draw them at their native size. If you need your images to actually be full screen, render them at the necessary resolution outside of SuperLab. When SuperLab restarts a trial due to feedback, it goes back through all of the trial initialization routines–the nasty time-consuming stuff that happens between trials instead of during trials. I chose some relatively small image files to replace the missing files, and it took a whopping 160ms PER IMAGE to scale it nicely from 320x320 up to 1920x1200. When I drew them at their native 320x320, it only took about 6ms per image to draw into the offscreen buffer. It probably would have been even less if they had been BMP or PNG files instead of JPEG (no compression).

As a side note, future version of the verbose log will note when SuperLab is drawing into an offscreen bitmap–thanks to your issue. :wink:

Hi Hank,

Thanks again for your speedy help. I want to be sure I understand the issue with the image size correctly…

I need the images to be presented full screen, but right now I have them compressed to the smallest jpg file possible (because I thought this would allow them to load faster) – If I understand you correctly, this small jpg size may be what is causing the slow down when the trial recycles? Thus, I should convert them to the actual full screen size and save as BMP or PNG files? Please let me know if I’ve got this right.

Really appreciate it,


That’s my theory, yes.

Thanks Hank! This seemed to work somewhat - I no longer have the “hesitation” that occurs when the trial is recycling, so one problem is resolved, but it still takes about 160 ms to load an image. Should I just add this time to the “input” time (the amount of time I want the event to remain on the screen)? So, in my case, if I want each image to be presented for 250 ms before moving to the next event, should I make the time 410 ms (250 + 160ms of loading)?