make_random_timing.py - using it for mixed design

[meiling]

AFNI version info (afni -ver): 23.1.10

Apologies for the basic question. I'm trying to figure out how past studies generated the stimulus timing file for the experiment.

I'm been looking at the documentation for make_random_timing.py and I'm confused on how to write the scripts for mixed design.

In the study, I have 4 stim_class (i.e., small_low, small_high, large_low, large_high).

The experimental task was broken down into 8 blocks, with a short 1 min break in-between blocks. In each run, there are 4 blocks.

In each block, there are 4 stimulus classes, repeated 6 times, resulting in 24 trials per block, 96 trials per run, and 192 trials per study.

Questions:

1. Do I put num_runs = 8 or num_runs = 2?
2. The stimulus class should not be consecutively after one another, so I set is as max_consec 1 1 1 1
3. Is there a way to include the fixation, question, and responses using the add_stim_class? That way, I will have start time for each stimulus presentation.

    make_random_timing.py -num_runs 8 -run_time 350         \
       -pre_stim_rest 10 -post_stim_rest 10                   \
       -add_timing_class stim 7.5                             \
       -add_timing_class rest 2 6.23 16                       \
       -add_stim_class small_low 6 stim rest                 \
       -add_stim_class small_high  6 stim rest                 \
       -add_stim_class large_low 6 stim rest                   \
       -add_stim_class large_high 6 stim rest                   \
       -max_consec 1 1 1 1                               \
       -show_timing_stats                                   \
       -write_event_list events2.adv.4                       \
       -seed 31415 -prefix stimesA.adv.4 -verb 2

[rickr]

Hello,

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.

1. What you have so far looks very good. But there are choices on how to proceed.

2. Yes, or you could specify it as "-max_consec 1".

3. 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)

Once this is decided, we can put things together.

• rick

[meiling]

Hi Rick,

Thank you for the reply. I really appreciate it.

@rickr

Creating timing files for the fixation and '=' presentations will be easy, too, though you presumably would not want to include them as regressors.

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.

@rickr

Note that as given, the question and response conditions will be highly correlated. Do those need to be modeled as separate events?

Yes, they are highly correlated and should be viewed as single events (i.e., each question follow the pre-determined response).

@rickr

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'.

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.

[rickr]

Hi @meiling,

Sorry for dropping this (amidst summer travel and such). Were you able to make some progress with this, or would it be good to revisit?

Thanks,

• rick