Unique conditions file for each participant based on participant number in Builder

Hi all,

I am using PsychoPy to present a questionnaire to my participants. More specifically, they do half a questionnaire with randomly selected items before a session in a different program, and they do the remaining items afterward.

With Python, it was reasonably straight forward to generate these lists beforehand, so now I have files such as ‘questionnaireA20.csv’ and questionnaireB20.csv’, where 20 is the participant number. I now have a version A and B of the .psyexp file, and let’s take the A-file as an example. The idea is that the A-file imports the A-list belonging to the participant number.

I attempted to achieve this by using the following code at “Begin Experiment”:

Which does not return an error and the print command reads exactly what I would expect it to.

However, the problem seems to lie with the other elements in the flow (as the Conditions field in Properties is now empty). On the screen, I want to present text as defined by a column in the conditions file, so I call it with $TextLeft in the builder, which is one of the headers.

This results in a NameError, because the name ‘TextLeft’ is allegedly not defined. And part of me can see how that is obvious, but not obvious enough to solve it.

Is there a way to circumvent it?

(I am currently using the Python 3 version even though I have more experience with 2.7. But that’s not a big deal, just takes a little longer with sorting the grammar/syntax). I’m not afraid of using code but I would like to be able to keep it all in the Builder because of reasons.

Many thanks in advance!

Just to clarify: Is there a specific reason why you don’t simply put the file name (i.e., $'questionnaireA'+expInfo['participant']+'.csv') in the Conditions field of the loop around your main trial routine?


1 Like

Beats me. probably because it almost seemed too easy. *Bows head in shame.

(To be fair, when I tried something similar on a different OS before, the field would return to being blank. But to be even fairer, that was probably due to a syntax mishap).

Thank you @jderrfuss.