[solved] Unprogrammed delay at the end of a sequence

ThijsNielen

Dear OpenSesame team,

I recently started working with your program as an alternative for e-prime (due to equipment with different versions e-prime gave compatibility problems). So far OpenSesame seems to be a great alternative.

However, there is one problem for which I hope you have a solution.

I have been working on two different tasks (visual dot-probe task and flanker task) for two projects. In both tasks I seem to get a problem with the duration of the intertrial interval (ITI).

First a little background information about the used devices and settings in general:

• I encountered the problem both at my computer (windows 7, 2.9 GHz processor, 4 GB RAM) and on my laptop (windows 7, 2.5 GHz processor, 4 GB RAM)
• In both experiments I use the Expyriment back-end
• I do not log all information, I select what I need (RT, presented stimuli, congruency, trialcount etc.)
• The visual dot-probe tasks works with pictures whereas the Flanker task works with text input, both presented in a sketchpad
• The ITI's are specified through an empty text display with a duration of 0 ms followed by an advanced delay with a duration (for the visual dot-probe task and flanker task respectively 1250 and 1500 with jitters of 500 and 750 ms).

In the visual dot-probe task I noticed that after specifying a break ("=self.get('count_exp_trial') % 34 == 33" in the run if option) the ITI seemed to be longer than the duration I specified.
A little experiment with a stopwatch comparing the visual dot-probe task in e-prime and in OpenSesame confirmed this suspicion. Timing 20 ITI's in both experiments resulted in a 600 ms difference (M eprime = 1757 vs M os = 2353) between the two programs.

When I started programming a Flanker task this morning I noticed the ITI being longer than specified even in a simple sequence with a fixation cross, stimulus presentation, keyboard response (timeout 2000 ms) and an ITI. Again the difference seems to be approximately 600 ms.

I solved this problem in the visual dot-probe task by splitting up the ITI in a fixed part of 200 ms right after the response and a random part of 450 (jitter 500) ms prior to the fixation cross. With a 600 ms delay this results in a comparable experiment as in e-prime. However, this seems to be a somewhat artificial solution.

Do you know how to prevent the delay at the end of a sequence?

Thanks in advance.

Kind regards,

Thijs Nielen

Edwin

Hi Thijs,

What could well be going on (especially if your trial sequence consists of a lot of sketchpads, and/or large images) is the loading time for the next sequence. OpenSesame works with a prepare & run strategy that comes down to the following:

1) Before a sequence, prepare all of the stimuli (with the exception of the feedback item). This preparation takes a bit of time (usually not 600 ms, though, unless you have a lot going on!). How long is mostly unpredictable, and could really mess up timing if you do it directly before showing stimuli.

2) Run all elements in the sequence, without weird timing hiccups during running.

So the extra bit of delay you're seeing might well be caused in the prepare phase. There are a couple of potential solutions, of which I'll give you the proper (accounting for timing), and the sleazy way (which, judging by your kind of tasks, should be fine):

Quick 'n Dirty

Adjust the advanced_delay's time to 600 ms lower than you have now.

Super Timing

Remove the advanced_delay item from your sequence. Then place the following code in an inline script at the very start of your sequence, in the Prepare phase:

# prepstart
exp.prepstart = self.time()

Place the following code in the Run phase of the same inline_script:

import random

# timing settings (mean ITI and jitter)
ITI = 1250
jitter = 500

# calculate the preparation time
preptime = self.time() - exp.prepstart

# calculate the actual pausing time (including jitter)
pausedur = random.randint((ITI - preptime) - jitter, (ITI - preptime) + jitter)

# pause!
self.sleep(pausedur)

Good luck!

ThijsNielen

Hi Edwin,

Thanks for your quick response.

I already applied the quick and dirty solution in one of the experiments, which works out fine. However, for the other one I would like to use the Super Timing. I understand the logic in the script and would like to implement it. However, when I opened the script editor and looked up the sequence I noticed that in the script of this experiment there seems to be no preparation phase. Because the experiment so far is very short I provide the full script which may make it easier for you to see what happens. Can you explain why there seems to be no explanation phase? And should I add this in the script?

It would also be very helpful if you could show me where you would implement the timing script (I am not very familiar with programming language).

Thanks for your help!

Thijs

Script:

# Generated by OpenSesame 2.8.3 (Gutsy Gibson)
# Wed Sep 10 15:53:30 2014 (nt)
# <http://www.cogsci.nl/opensesame>

set mouse_backend "xpyriment"
set subject_parity "even"
set height "768"
set font_family "mono"
set font_italic "no"
set synth_backend "legacy"
set title "New experiment"
set coordinates "relative"
set start "experiment"
set sampler_backend "legacy"
set transparent_variables "no"
set foreground "#ffffff"
set font_bold "no"
set description "Default description"
set background "#000000"
set font_size "18"
set keyboard_backend "legacy"
set canvas_backend "xpyriment"
set compensation "0"
set bidi "no"
set subject_nr "0"
set width "1024"

define text_display ITI
    set foreground "#ffffff"
    set font_size "18"
    set description "Presents a display consisting of text"
    set maxchar "50"
    set align "center"
    set content ""
    set background "#000000"
    set duration "0"
    set font_family "mono"

define advanced_delay ITI_timing
    set duration "1500"
    set jitter "1500"
    set description "Waits for a specified duration"
    set jitter_mode "Uniform"

define sequence experiment
    run text_display "always"
    run practice_loop "always"

define fixation_dot fixation_dot
    set foreground "white"
    set style "cross"
    set description "Presents a central fixation dot with a choice of various styles"
    set duration "250"
    set background "black"
    set y "-2"
    set x "-4"
    set penwidth "3"

define keyboard_response keyboard_response
    set correct_response "[CorResp]"
    set allowed_responses "a;l"
    set description "Collects keyboard responses"
    set timeout "2000"
    set flush "yes"

define logger logger
    set ignore_missing "yes"
    set description "Logs experimental data"
    set auto_log "no"
    set use_quotes "no"
    log "response"
    log "response_time"
    log "subject_nr"
    log "correct_keyboard_response"
    log "CorResp"
    log "Stimuli"
    log "congruency"
    log "count_practice_seq"

define loop practice_loop
    set repeat "1"
    set description "Repeatedly runs another item"
    set skip "0"
    set item "practice_seq"
    set break_if "never"
    set column_order "Stimuli;congruency;CorResp;Location"
    set cycles "6"
    set order "sequential"
    setcycle 0 CorResp "l"
    setcycle 0 Stimuli ">>>>>"
    setcycle 0 Location "0"
    setcycle 0 congruency "0"
    setcycle 1 CorResp "a"
    setcycle 1 Stimuli "<<<<<"
    setcycle 1 Location "8"
    setcycle 1 congruency "2"
    setcycle 2 CorResp "a"
    setcycle 2 Stimuli ">><>>"
    setcycle 2 Location "0"
    setcycle 2 congruency "1"
    setcycle 3 CorResp "l"
    setcycle 3 Stimuli "<<><<"
    setcycle 3 Location "8"
    setcycle 3 congruency "3"
    setcycle 4 CorResp "l"
    setcycle 4 Stimuli "□□>□□"
    setcycle 4 Location "0"
    setcycle 4 congruency "8"
    setcycle 5 CorResp "a"
    setcycle 5 Stimuli "□□<□□"
    setcycle 5 Location "0"
    setcycle 5 congruency "9"
    run practice_seq

define sequence practice_seq
    set flush_keyboard "yes"
    set description "Runs a number of items in sequence"
    run fixation_dot "always"
    run sketchpad "always"
    run keyboard_response "always"
    run ITI "always"
    run ITI_timing "always"
    run logger "always"

define sketchpad sketchpad
    set duration "0"
    set description "Displays stimuli"
    draw textline [Location] -4 "[Stimuli]" center=1 color=#ffffff font_family="mono" font_size=46 font_italic=no font_bold=no show_if="always" html="no"

define text_display text_display
    set foreground "white"
    set font_size "18"
    set description "Presents a display consisting of text"
    set maxchar "100"
    set align "center"
    __content__
    Welkom

    Er verschijnt straks steeds een rij van vijf tekens op het scherm.
    De middelste is altijd een pijl. 
    Jij moet aangeven naar welke kant de middelste pijl wijst. 
    Als de pijl naar links wijst druk je op de A, als de pijl naar rechts wijst op de L.

    Probeer steeds zo snel mogelijk te drukken zonder fouten te maken.

    We gaan eerst even oefenen, druk maar op de spatiebalk om te beginnen.
    __end__
    set background "black"
    set duration "keypress"
    set font_family "mono"

Edwin

Ah, yes, there seems to be some confusion. In OpenSesame, there is indeed the OpenSesame syntax that you have copied in here. This, however, is very descriptive and not the script I was referring too.

What I was referring to, is Python inline script, which you can use within inline_script items. These do have a separate Prepare and Run Phase in the visible bit (the rest of the elements are always, even if you cannot see it in the OpenSesame syntax, divided in those two faces, all automatically).

So add one of those inline_script elements to your sequence, and place the code above in the appropriate phases.

Good luck!

ThijsNielen

That explains a lot, thanks!

I added an inline_script item and it worked out fine.

One comment about your script (to avoid error messages):
"preptime - self.time() - exp.prepstart" should be "preptime = self.time() - exp.prepstart".

Thanks for your help. I will do some more timing but as far as I can see now it seems to work as expected.

Edwin

Sorry, that's a typo. Thanks for noticing! Great that you've got things sorted now, I'll mark this as solved.

ThijsNielen

Hi Edwin,

Unfortunately I run into another problem. The inline script works fine in the practice and experimental trials, until I add a break. I have a simple text display followed by a keyboard response (space in this case) as a break option that I want to run after 60 trials. I used the following specification in the sequence menu for both items: Run if: [count_exp_seq] = 60. This results in a massive delay of the ITI (from an average of 2000 till an average of 4000 ms. Do you know why this happens and how I can prevent this?

Thanks!

Thijs

ThijsNielen

N.B. without the break inserted everything is running fine, so I'm pretty sure its the break.

Edwin

Hi Thijs,

The obvious solution would be to reduce the amount of elements for your break to a single sketchpad, with a Duration set to keypress (you don't need more!). If all you present on that sketchpad is a line of text (e.g. "Press space to continue"), it should not take such a long time to load. Unless you're running OpenSesame from a potato

Additionally, please keep in mind that the placement of the pause is quite an important factor. Of course there is going to be a delay if you ask people to take a short break, so do not place it where timing is crucial. A nice place would be at the very end of your trial sequence.

Good luck!

ChiaraDL

Hello everyone, I am also experiencing Thijs's problem with the break.
I would like to insert a pause every n trials, and when I add the pause with the conditional statement (e.g.,("=self.get('count_exp_trial') % 34 == 33")) at the end of the trial sequence this seems to introduce a systematic delay at the end of each trial.
Even with a break object terminating with any keypress.
This does not affect the timing between trial events, but it becomes a problem in term of general timing of the experiment, adding 1 or 2 seconds to the duration of each trial...
It seems strange though that such a simple computation would cause such a delay...
There must be for sure one way to get through it, right?

Thanks for any help,
Chiara

sebastiaan

Hi Chiara,

It seems strange though that such a simple computation would cause such a delay...

The conditional statement only prevents the run phase from being executed. But the item is still prepared, and this can introduce delays. So it's not the run-if statement itself that causes the delay.

To avoid this, you could use an item that is not prepared at all, such as a feedback item. Or you could wrap the item in a loop. (This works because preparation occurs at the sequence level.)

See also:

• http://osdoc.cogsci.nl/usage/prepare-run/#conditional-statements-run-if-and-show-if

Hope this helps!

Cheers,
Sebastiaan