Two-second delay after logger

pbe

Dear All,

I would like to ask for advice regarding an unexpected delay of two seconds after a logger. The issue resembles others previously reported (https://forum.cogsci.nl/discussion/1260/open-timing-accuracy-and-stimuli-onset-times).

I have done the math to calculate the delay between the logger, which is the last part of the trial, and the first part of the next trial. I provide a screenshot of the calculation made in Excel, where I interleaved extra rows to place the calculations.

The image depicts the initial trials (1--8) and the final trials (34--39) in a block (after which participants have a break). I hid the rows containing the intermediary trials to facilitate the visualisation.

The result shows a varying delay of around 2 seconds on average.

It would be very helpful for us if we could cut down this delay, as it adds up. To try to achieve this, I reduced the number of variables logged, from the default 363 to 34 important variables. Unfortunately, this change did not result in a reduction of the delay.

I would be very grateful if someone could please have a look at the session to see if something else could be tried. If need be, we will of course remove our intertrial interval item to partly reduce the overall ITI.

If you would be so kind, please download the session materials at https://drive.google.com/drive/folders/1Ahr--GntSKxIEUtTMp_YtqVhpvwEAWQF?usp=sharing. After extracting the materials, please start the session and follow the next steps:

• for the subject number, please enter 1 or 3 or 5 ... (an odd number between 1 and 143);
• press the letter C twice to advance beyond the first message screen;
• select the 'Experiment' checkbox and click on the Confirm button;
• press the letter C twice to advance beyond any of the screens containing orange-coloured stripes;
• press the space bar twice to advance beyond the other instruction screens;
• the experiment will begin then. Please complete a few trials by right-clicking or left-clicking at the end of the succession of single words.
• after a few trials, quit the experiment by pressing ESC.
• please find the logfile in the main directory. Using this logfile, please consider verifying the delay I have reported. To this end, please enter a new row above after the third row. Therein, please enter the formula =AD4-AC4 in the AO column, and then enter the formula =AB6-AD4-AD5 in the AF column.

Thank you very much for reading this and for any further attention.

Pablo

pbe

Continued.

The current is compatible with OpenSesame 3.3.14, and likely incompatible with the latest version of OpenSesame.

The delay is influenced by the condition of the computer, with two seconds being observed in a good computer. In a slower computer, an average delay of seven seconds has been observed.

Fab

Hi @pbe,

I've had a quick look at your task but I can't identify anything obvious that would explain this delay. there must be something running in the background that is labor intensive (hence the different delays depending on how fast the computer is.

Here are some suggestions you may want to try to trace the source of the issue.

• Try changing the back-end to see if it makes any difference.
• Strip down the task to the experimental part, keeping it to the bare minimum (even removing the bits of code sending the triggers) to see if the issue persist. If it does not, reintroduce the rest of the experiment step by step and try out the task to see at what stage the issue resurfaces.
• Give Open Sesame 4 a go. Though there can be exceptions, in principle the current version should be able to run experiments programmed under version 3.

That's all I can think of at the moment. Let's see if any of the suggestions above helps.

Best,

Fabrice.

pbe

Hi Fabrice,

Thank you very much!

By following your advice and a couple more steps, I have reduced the delay to 1,030 ms on average, with values ranging between 940 and 1,076 ms. This was mainly achieved by constraining the conditionally-controlled items in the timeline.

• I first tried changing the back-end to psycho, but it didn't help.
• Next, I placed the logger before the break that is presented conditionally. That reduced the delay to around 1,900 ms.
• Next, I removed an expendable sequence within the sequence, which contained instructions that were presented only in case of low performance. That reduced the delay to around 1,700 ms.
• Next, I replaced several sketchpads with feedback items, following https://forum.cogsci.nl/discussion/comment/4798/#Comment_4798. This reduced the delay to around 1,500 ms.
• Next, I removed two keyboard responses that served to constrain the advancement from a sketchpad to two space bar presses. Instead of this constrain, I allowed any keypress in the preceding sketchpad. This reduced the delay to around 1,200 ms.
• Last, I raised the battery settings of my laptop to full performance, and closed the internet browser and the Outlook app, which reduced the duration to 1,000 ms.

I cannot sacrifice other items in my session, so I think it's unlikely that I could further reduce the delay. I guess the delay could be moved across various points, by switching between the prepare and the run phases, but I think that a certain amount of preparation time is unavoidable. The key is to keep this delay controlled, so that it doesn't happen where it would be critical in a trial.

Regarding the version of OpenSesame, a couple of months ago I tried running the experiment in OpenSesame 4, but it did not work. My experiment has several inline scripts, and I read in the release notes of the new version that some adaptations would be required. Due to time constraints, I abstained. I will give it another try sometime.

Thank you very much. Go OpenSesame!

eduard

Hi Pablo,

Looking at your experiment, it appears to be quite large. And also unnecessarily so. Perhaps you can reduce the size of it, by splitting it up in separate experimental files? For example, an English and a Norwegian version. As well as separate files for the different sequences you want to run. It seems like, these options are more or less hard-coded (the experimenter sets certain variables in the beginning accordingly), so the progression of the experiment does not depend on what a user does. If so, you can reduce the number of items considerably by using separate experimental files. This should help with less delay, as fewer things need to be prepared in between sequences.

What you can also do, is replacing the ISI sketchpads, with advanced delay items. They are much simpler and require less preparation than sketchpads.

You can also save items, by setting the duration of some of the sketchpads to keypress instead of having them being 0 and 2 keyboard items (whose response you don't care about).

You can try to use a loop with one sequences instead of separate sequences for the eyes open/closed sequences. The few differences between them (instructions, trigger code), you can pass on via the loop table. Similarly you might be able to reduces the number of sequences further, I have not checked all of them.

There might be more things to save, particularly in the experiment and training sequences, but they look too complex for me too really get what is happening. If you apply the same tips from above, I am sure you can save a couple of hundreds of ms more.

Good luck,

Eduard

ps, Finally, unrelated to your problem, but you might want to consider to have a fixdot on the screen during eye open restingstate. Like so participants are less inclined to drift away with their gaze.

pbe

Hi Eduard,

Thank you very much. I will apply as many as of your suggestions as possible.

• Regarding your first point, I'll need to consider some trade-offs. For instance, I would need to ensure that the additional time saved is not lost while opening various OpenSesame files within a lab session. I also need to consider the added possibilities of human errors during the creation of parallel files and during their in-lab manipulation. At any rate, it's good and useful that you raised this point.
• I'll definitely change the ISIs.
• I may indeed have to remove more space bar progressions, as well as simplify another kind of special progression I have.
• I'll definitely implement the loop for the rs-EEG.

In the eyes-open condition, the instructions advise participants to fix their gaze under the arrow at the bottom of the screen (to save them a bit of eyestrain caused by the screen).

Thank you very much, and all the best,

Pablo