| Reference | Downloads | Github

Non-slip timing for variable trial length information from input file

The documentation states:

When creating experiments in the Builder, PsychoPy will attempt to identify whether a particular Routine has a known endpoint in seconds. If so then it will use non-slip timing for this Routine (…). Routines that are able to use this non-slip method are shown in green in the Flow, whereas Routines using relative timing are shown in red."

What if I would like to define the length of a routine based on a column in the input file (to achieve variable intertrial intervals)? When I set the trial up, the endpoint of the routine will not be known, so it will be displayed in red. Will the non-slip timing work nevertheless?

I suspected that the answer would be yes, but after looking at the compiled script I realise that the answer is actually no:

    # the Routine "trial" was not non-slip safe, so reset the non-slip timer

I assume there is no hidden tick box that says “It might seem like the endpoint isn’t known, but it actually is.”? So, I guess the only workaround would be to use the Coder? Or is there another solution that I can’t think of right now?


This is indeed a current limitation of Builder. It shouldn’t be hard to fix but we haven’t got around to it. (Have discussed it with @jon before but now I look back through my files, I didn’t document the issue properly, so if you can work through this and report back here, it would be very useful for us to get a fix sorted.)

Yes and no. Currently, there should be a simple workaround where you design and create the experiment in Builder but then do a simple edit to the generated .py file. After that, you will need to run that edited .py script from within Coder (as Builder would overwrite your changes each time it runs).

I’m struggling to recall my solution, but I came across this same problem earlier this year when I wanted to create a quick and dirty fMRI paradigm using Builder but found that the timing wasn’t acceptable over the course of the several minutes of the protocol. This was due to it not using non-slip timing, for the reason you’ve identified.

I think the solution was something like this:

Say you have a stimulus duration that you want to be controlled by a variable from your conditions file but also want non-slip timing. Instead of your variable name, insert a distinctive numeric value (like 9.99) in the duration field. When ready to test your experiment, don’t push the green Run button but instead the Compile script button on the toolbar. In the Coder window that opens, do a find and replace for 9.99, and replace all instances of that with your variable name. Save that script with a new name. To run your actual experiment, open that script file rather than your Builder file, and run it from within Coder.

Hey presto, you should have an experiment structured around non-slip timing but that will use variable durations rather than fixed numeric values. You are still responsible for ensuring that your duration values are sensible multiples of the frame rate (e.g. on a 60 Hz display, a stimulus can be displayed for 50 ms or 500 ms but not, say 60 ms or 520 ms).

Let us know if the solution above works and gives you good results. If this is actually what I did, I found the overall duration of the task to be within a couple of milliseconds of the intended duration for a run of 6 min 24 s, whereas without non-slip timing, the total duration drifted by quite a few seconds as the lags accumulated.

You don’t need to look at the compiled script: Builder shows routines in green in the flow panel if they have non-slip timing, and red otherwise.

Lastly, think about whether you actually need non-slip timing. It is often really only necessary for things like fMRI studies, where timing across trials needs to be taken into account as well as timing within trials. You might actually find that non-slip timing may not be necessary, or even desirable, for your particular requirements.

1 Like

Thank you for your detailed reply, Michael. This is much appreciated.

Sorry, I should have been clearer. This is actually what I meant.

I will keep this in mind.

Will do. It might take me a while to put the actual experiment together though. I had just created a dummy experiment the other night to see if the general approach would work or not.

Yes, I was somehow hoping that the colour might not be a reliable indicator in this case (i.e., when the red colour is caused by using something like $trialLength as the duration of a component vs. when it is caused by “Force end of Routine” for a response component). :slight_smile:

Sure. Just to confirm: The study is an fMRI study. :slight_smile: