Hi Kathryn,

The catch trial method seems reasonable. I could actually implement that locally if I added an option to combine classes together. Maybe that can go on the "todo" list.

I was not aware of that package you are linking the program under. Note that the version you link to is 4 years old. Our current version has many new features. See make_random_timing.py -help .

In any case, your interpretation seems good. The catch trials are designed as separate classes, which can be combined later.


So the full trials need to be TR-locked for some reason? That is actually harder to do, as you are seeing. The effect is just the Cue events start on the TR, but not task events.
Is this interpretation accurate?
To be sure, why this is necessary?



How long can a full trial be? That ITI comes in multiples of 2.5 puts big jumps in the event times that is a little odd. Were you planning to impose a full trial length limit of 10 s, for example?

Is the a minimum Cue or ITI duration? I guess min(Cue+ITI) = 1 s. Should they both have a minimum of 0.5 s, or maybe min(ITI)=1 s?

In your script example, the Cue events are always 1.25 s, so the Task events start in the middle of a TR. Also, it then seems odd that Cue+Task = 2.75 s = 0.25 s longer than a TR, when you want the overall timing TR-locked. Is that what you want? I just want to be sure.

So basically these Cue/Task/ITI events would have to be treated as single events, and then the interior Task phases would have to be randomized within. This is scriptable, but might be a touch messy. If Cue and Task are really fixed durations, then this might be doable differently.

Anyway, maybe it would be good to let you respond to my questions before going into the weeds with details.

Thanks,

- rick