| Reference | Downloads | Github

PseudoRandom Routine without 4 of the same presentations in a row

Hi everyone,

I had a question about creating a looped routine that chooses the trial type using an Excel file. I need the trial type to be chosen randomly without replacement which I achieve by using the the ‘random’ loop type. There are 8 CS+ and 8 CS- Trial types. The nature of my experiment requires us to have no more than 3 CS+ types in a row so is there a way to code in the builder view that will prevent PsychoPy from choosing 4 CS+ types in a row?

The code looks like this;

d.getFeedback(u3.BitStateWrite(smell,1)) #open a valve
d.getFeedback(u3.BitStateWrite(12,1)) #close NO

‘smell’ is defined in the Excel file. There are 16 rows; eight of which are CS+ and CS-.

It’s not really possible to impose those sorts of constraints using the standard Builder loop dialog.

You probably will need to write some code to construct the random but constrained orders you need, but even that is tricky. I’ve never found a better way than brute forcing it by creating a random selection, checking to see that it meets the constraints, and if not, loop back and create a another selection, and so on.

An alternative is that you hand-craft a set of random but constrained conditions files your self, and then assign subjects equally to those across sessions. i.e. specify the name of one of say, 4 conditions files to use in the information dialog box at the start of the experiment.

1 Like


Your point is quite interesting to me as I am now confronted with a similar problem.

Do you think that it would be possible to check the current random selection for a certain loop and - if necessary- force the creation of a new one that meets the desired criteria and then feed it to the loop properties with some code snippets in the Builder, or this is rather something that is only feasible in Coder view?

Any advice/help on the matter would be greatly appreciated.

This sort of thing can be done in the Builder by inserting a Code component and putting code to run in the Begin Experiment tab. i.e. The code needs to create and save a conditions file before any loop that refers to it gets created.

So from that point of view, yes, this stuff can be done in Builder. But you wouldn’t want to be trying to run code that tries to manipulate and select conditions while a loop is running. That could cause all sorts of headaches.

The only reason to go the Coder route is because you want to change the selection of conditions on a trial-by-trial basis, rather than use a “pre-baked” conditions file. In Coder, you can be in control of everything, so have the flexibility to do that. But, of necessity, it is more complex.

1 Like