Unwanted delay between trials

Charlotte_

Hi! So, I've made a test of temporal order judgement, but I have a weird delay between each trial, that I cannot figure out the source of.
First I have a practice sequence, which works fine. The delay only exist in the experimental sequence. In the picture is the structure of one part of the experimental sequence (the other part is very similar). In this part there are two sequences, delay_sequence_40 and delay_sequence_60 (the latter part of delay_sequence_40 didn't make it in the picture, but it is the same as in delay_sequence_60).
The time between "cue" and "certainty_response" works just fine, it is the delay after the response was made and until the cue turns up again that is the problem. I have tried to delete the "delay before cue" but there is still a delay of about two seconds. The sketchpads are set to 16 ms (so they should be shown for 16,67 ms). Any idea of what might be wrong?

sebastiaan

Hi Charlotte,

I think there's nothing wrong per se, but you're just seeing a long preparation time that results from the many items that you have in your injected_delay_sequence. In OpenSesame, to ensure that timing during a sequence is as good possible, each sequence is preceded by some variable preparation time. You can read more about this here:

• http://osdoc.cogsci.nl/3.1/manual/prepare-run/

Two seconds is quite extreme though. My guess is that you're using either the psycho or xpyriment backend, and that your system is struggling with the way these backends handle stimulus preparation. If you switch to the legacy backend, you may find that things go smoothly again. (Although some preparation time will always be there.)

Cheers!
Sebastiaan

Charlotte_

Thank you for your answer! That explains why I couldn't find any specific mistake.
However, the experiment is dependent on millisecond temporal precision so I'm not sure if the legacy backend would work. I might have to accept the delay, then, if there aren't other ways to deal with it?

/Charlotte

sebastiaan

I might have to accept the delay, then, if there aren't other ways to deal with it?

You can try to optimize various things. For example, I'm guessing that you're running delay_sequence_60 or delay_sequence_40, but never both, right? Nevertheless, both are prepared now, so both add to the preparation time. A simple workaround would be to wrap both of these sequences in their own loops that do nothing except run the sequence. Like so:

injected_delay_sequence
    delay_loop_60
        delay_sequence_60
    delay_loop_40
        delay_sequence_40

This works, because the prepare-run strategy occurs at the level of the sequence; or, phrased differently, a loop prepares its item-to-run during the Run phase. Does that make sense? (It sounds more complicated than it is.)