Sorry for being slow, I have been away. Also, I have not gotten around to managing this sort of nested design nicely, where events are made up of sub-pieces. On the plus side, it looks like all of the sub-pieces are at fixed offsets. On the down side, the program cannot handle the blocks with 1-minute breaks. So this might take some construction.
What you have so far looks very good. But there are choices on how to proceed.
Yes, or you could specify it as "-max_consec 1".
Yes, you could have one event following a fixed different one. However, it might be a little more clean to just save that for later. The time offsets are fixed, so it isn't necessary to create the sub-events initially.
Creating timing files for the fixation and '=' presentations will be easy, too, though you presumably would not want to include them as regressors.
Note that as given, the question and response conditions will be highly correlated. Do those need to be modeled as separate events?
But to be sure, do you want to restrict the total rest timing to be consistent per block (choice 'a') or consistent per run while varying per block (choice 'b')? Based on your MRT.py example, you are leaning towards choice 'a'.
Specifically, the average rest period looks like 6.5 s, as (350-20 - 24*7.5)/23 = 6.521739. So how do you prefer rest partitioned?
a. 6.523 s per block
b. 6.523*4 s per run (the block lengths are allowed to vary here)
(not including the 10 s offset and 1 m block separation)
Sorry for the confusion; according to the paper that I'm referencing, "In each model, these periods of interest were specified as 3 s long boxcar functions (commencing at problem onset) and then convolved with SPM's canonical hemodynamic response function (HRF)." So, I just need the timing for the onset of multiplication problems.
Yes, they are highly correlated and should be viewed as single events (i.e., each question follow the pre-determined response).
According to the cited paper, the average of the jitters across all the blocks are 6.23s, so I am suspecting it is choice a too.
The other questions that I have is, does the jitter needs to be in one-tenth seconds? I'm using PyschoPy and the FPS is 60hz, so would it be better if the jitter interval is 1s. For example, 2, 3, 4, 5, 6 seconds etc.