After several hours failing to get PEBL working, I’ve been coding up some scripts for a computerized testing battery in PsychoPy. I really like it overall; it covers PyEPL‘s major deficiency of not being able to create arbitrary stimuli online, and the learning curve is much gentler, at least for someone who doesn’t know much Python in the first place. It doesn’t enforce certain good habits that PyEPL does (e.g. segregating config files, obsessively logging everything), and I can’t figure out how to change the awful font choices in the editor or (just as good) get it to run from plain Python rather than within the PsychoPy app — but overall I’m well pleased.
I’ve run into two real problems in the last week or so of semi-intensive PsychoPy programming that I wanted to share with the Internet (and, possibly, my future self). Neither is a problem in the sense of “PsychoPy fails at x”; they’re problems in the sense of “This is an approach that might seem reasonable, but it won’t work.”
- Vertices of
ShapeStimshapes. This is actually documented, but I didn’t notice it for a while, so here it is again: Vertices are offsets from the
posargument to the
ShapeStimobject. If you give the damn thing vertices with absolute screen positions, the resulting shape will be shaped right, but the size will be all messed up. You actually might only notice this if you need to put
PatchStimson the same screen — but you’ll notice then, mark my words.
Related: I’ve confirmed the documentation’s admission that filling breaks for shapes that have concavities. Creating those shapes out of their convex components, however, works just fine. Also, it looks like giving a filled shape a
depthargument of anything other than the default causes the lines, but not the fill, to take that depth — as far as I can tell, the fill just disappears in these situations.
- The proper way to wait for keypresses. Coming from a very old version of Psychtoolbox, or perhaps just from the Land of Bizarre Programming Practices, I’m accustomed to waiting a certain amount of time
t(but no longer) for a keypress by doing something like this:
while trialTime < t:
.... update trialTime
.... check for keypresses
.... if there are any, record RTs, process them, and break
If you do this in PsychoPy, the natural idiom to use for the “check for keypresses” step is
event.GetKeys. This approach will miss a lot of keypresses. It’s not a subtle issue, luckily; your program will just fail to respond to something like four out of five keypresses. However, there’s actually no need to use this structure.
maxWaitargument that serves just as well to enforce the time limit (something it took me a while to realize), and you can record RT just by resetting a clock before the
WaitKeyscall and recording time from that clock after it. I don’t understand why the for loop over
GetKeyshas this issue, but I haven’t detected any drawbacks to just using