resolutions to a couple of psychopy issues

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

  1. Vertices of ShapeStim shapes. This is actually documented, but I didn’t notice it for a while, so here it is again: Vertices are offsets from the pos argument to the ShapeStim object. 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 ShapeStims and RadialStims or PatchStims on 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 depth argument 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.

  2. 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. event.WaitKeys has a maxWait argument 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 WaitKeys call and recording time from that clock after it. I don’t understand why the for loop over GetKeys has this issue, but I haven’t detected any drawbacks to just using WaitKeys instead.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s