Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Supported by

Solution for long unwanted time delay between trial sequences?

Dear all,

In the first part of my experiment I am exposing participants to a continuous stream of shapes, presented one by one. This stream is made up of 6 pairs (2 shapes that always come together) and only the transitional statistics should provide a cue for the pairs, the breaks between shapes always being 500ms.

I implemented this part of my experiment by defining the presentation of a pair as a trial sequence. However, this gives me a big timing issue. Within a trial sequence the timing is perfect (refresh rate is 100Hz and I'm asking for 8ms less , but their is a long unwanted delay added between trials (added to time_SLblank3, see timingSLtrials tab in the attached excel file). Reading the documentation I understood that this is because "the timing within a sequence is not confounded by stimulus-preparation time".

My question is what would be the best way to overcome this issue as I am using the sequence and block loop levels to make sure (1) shapes in a pair are always presented one after the other, (2) all pairs are presented in random order within a block and (3) there are several repetition blocks defined by the number of pattern repetitions we want to give (see code attached). Are there tweaks to improve the timing on the loop level I can try? Or will it per definition be necessary to replace the entire SL part of my experiment by an inline script at the highest loop level (if so, some hints of how to go about this would be very welcome)?




  • edited November 2019

    Update: I found out that the removal of a redundant sequence element that was containing only block_loop_SL was partly responsible for the problem. However, even when I move block_loop_SL directly into SL loop I still observe an added preparation time between trials of about 100-150ms, but up to 400ms in rare cases. As the delay is not constant I can not simply subtract it from the last blank screen in the trial sequence.

    Does anyone have a suggestion for reducing preparation time or its jitter between run i and  run i+1  of the loop over the trial sequence without having to create a very long trial sequence that basically encompasses the presentation of all pairs in random order (this is what I can think of)?



Sign In or Register to comment.