2

I understand that routines will use non-slip timing when the duration is fixed, as denoted by being green in the flow. The duration of my routine is fixed in a way, as ending the routine does not rely on a response. However, the duration of the components does change by a pre-defined amount (variable ISI dictated by condition in a spreadsheet)... As in '$ISI + 1'.

My routine refuses to be green when I specify the duration by a condition... But it is still fixed...? I aim to use EEG with this experiment hence timing is extremely important. That being said- should I be timing by frames rather than non-slip anyway? The documentation hints to non-slip being better for imaging, but I am slightly confused as to why.

Thanks for your time, Grace

nobody
  • 19,814
  • 17
  • 56
  • 77
Ceretellum
  • 21
  • 2

2 Answers2

3

Actually for EEG I don't think this is really the right timing mechanism anyway. The non-slip timing stops gradual drift but doesn't improve accuracy for short periods; it's designed to prevent small overshoots from summing (in fMRI you don't care if a stimulus overshoots by 5ms but you don't want to drift by 5ms per trial). For EEG you need to prevent those overshoots from occurring at all because an error of 5ms is already a big deal.

I'd really recommend sending hardware trigger pulses (parallel port or labjack) to sync the stimulus with the recordings. And yes, I would also recommend using number of frames to handle timing (assuming your stimuli are relatively brief).

best wishes, Jon

Jon
  • 1,198
  • 7
  • 8
2

Unfortunately this is a limitation of Builder right now - it can’t figure out from code whether it should be non-slip or relative, so it defaults to relative timing. Although the timing is still fixed and known before-hand, builder doesn’t realize this. In general we recommend that people time by frames whenever precision is required, which is almost always, so it’s not a bad thing to do. And since standard displays are 60Hz, it’s usually straightforward - just use 16 and 2/3ms for the frame duration and calculate frames/times from that.

The trade-off between relative and non-slip timing has to do with whether you care more about getting the exact timing of stimuli or the exact total run-length to be correct. Relative timing is better for psychophysics/vision research as the exact number of frames for a stimulus are displayed, but there are possibly a few frames of “setup” timing that can extend the total length of the experiment. Non-slip timing ensures that the total duration will be set exactly, but can cut trials/stimuli a few frames short to make sure that the total duration will be constant, which is important if you need to stay in sync with scanner TRs / reps.

We were planning to add a non-slip max time for a routine during our code sprint last week, but didn’t get to it. If people are interested in that feature we could bump up its priority, and it could realistically show up in the next release. Unfortunately the last time we discussed it was quite some time ago on our development list here: https://groups.google.com/forum/#!topic/psychopy-dev/C7Lp1GSk974 ), but it’s on the list of features that will hopefully be added soon.

In lieu of a fix in builder itself, you could write your experiment in coder, or switch out relative timing for non-slip timing in the script that gets compiled from builder. Hopefully we’ll get a fixed pushed up relatively shortly, though!

Hope you can hold out, or adjust your script manually. When we incorporate the changes I'll post an update to the question to let you know.

Erik Kastman
  • 528
  • 6
  • 17