No, you really should just need one routine to run the trials, and a second one to do something crafty. The cleverness here should come from nesting several loops around those trial routines, to control the blocks.
I would say that you would need to nest your routines within three levels of loops:
- the outer-most loop encompasses everything . It will be connected to an “über” conditions file, which actually controls what block-level conditions files will be used. i.e. this conditions file will have 32 rows. Let’s call this loop
blocks
.
- the middle-level loop encompasses both routines. It won’t be connected to a conditions file. It will just be set to have an
nReps
value of 2. This will allow us to control what happens mid-way through “volatile” blocks. Let’s call this loop splits
.
- the inner-most loop will actually run the trials. It will only encompass the trial routine. i.e. the other routine comes before the trial routine but is not nested within this inner-most loop. We won’t directly connect this loop to a conditions file: instead we will use a variable name that comes from the “über” conditions file. Let’s call this loop
trials
.
The “über” conditions file should look something like this (with 32 rows of data + the header row):
cued stable proportion_1 proportion_2 trial_file_1 trial_file_2
yes yes 0.7 0.7 yy_7_80_A.xlsx
yes yes 0.9 0.9 yy_9_80_A.xlsx
yes no 0.7 0.9 yy_7_40_A.xlsx yy_9_40_A2.xlsx
yes no 0.9 0.7 yy_9_40_A.xlsx yy_7_40_A2.xlsx
no yes 0.7 0.7 ny_7_80_A.xlsx
no yes 0.9 0.9 ny_9_80_A.xlsx
no no 0.7 0.9 ny_7_40_A.xlsx ny_9_40_A2.xlsx
no no 0.9 0.7 ny_9_40_A.xlsx ny_7_40_A2.xlsx
yes yes 0.7 0.7 yy_7_80_B.xlsx
yes yes 0.9 0.9 yy_9_80_B.xlsx
yes no 0.7 0.9 yy_7_40_B.xlsx yy_9_40_B2.xlsx
yes no 0.9 0.7 yy_9_40_B.xlsx yy_7_40_B2.xlsx
no yes 0.7 0.7 ny_7_80_B.xlsx
no yes 0.9 0.9 ny_9_80_B.xlsx
no no 0.7 0.9 ny_7_40_B.xlsx ny_9_40_B2.xlsx
no no 0.9 0.7 ny_9_40_B.xlsx ny_7_40_B2.xlsx
# etc
You can come up with your own naming convention for the conditions files, but above they just encode the conditions used. The idea is that for “stable” blocks, you will only need a single conditions file (the ones labelled “80” above), which will have 80 rows. For “volatile” blocks, you’ll need to provide two files, each of 40 rows (labelled “40” above). The “A”, “B”, etc reflect multiple versions of your files, which might or might not be required depending on your design (i.e. it might be possible to just have 8 rows in this file but set the Reps
value to 4
to get your 32 blocks). I’m not entirely clear about the information that needs to be in these files (it depends on the .wav files you are using), so it is quite possible that you could actually have quite a small number of these files, rather than lots of individually-named ones as the table above currently implies.
Here comes the magic. In the non-trial routine (the one that is inside the splits
loop but not inside the trials
loop), insert a code component (from the “custom” components panel). In its “begin routine” tab, we will put some code to decide what conditions file will run on this block:
if stable == 'yes':
condition_file = trial_file_1 # 80 trials
splits.finished = True # only one iteration needed
else: # volatile, so change files as needed
if splits.thisN == 0:
condition_file = trial_file_1 # 1st 40 trials
else: # 2nd iteration, so switch file:
condition_file = trial_file_2 # 2nd 40 trials
Put $condition_file
in the conditions field of the trials
loop.
The first routine doesn’t need any stimulus components: it’s only function is to run the custom code above.
You should set the trials
and blocks
loops to be random order as needed.