Programming experiments using PsychoPy – first impressions

Links to PsychoPy websiteI wrote a tiny post about PsychoPy a little while ago and it’s something I’ve been meaning to come back to since then. I’ve recently been tasked with an interesting problem; I need an experimental task for a bunch of undergrads to use in a ‘field study’ – something that they can run on their personal laptops, and test people in naturalistic environments (i.e. the participants’ homes). The task is based on a recent paper (Rezlescu et al., 2012) in PLoS One, and involves presenting face stimuli that vary in facial characteristics associated with trustworthiness, in a ‘game’ where the participant  plays the role of an investor and has to decide how much money they would invest in each person’s business. I was actually given a version of the experiment programmed (by someone else) in Matlab using the Psychtoolbox system. However, using this version seemed impractical for a number of reasons; firstly Matlab licences are expensive and getting a licenced version of Matlab on every student’s computer would have blown the budget available. Secondly, in my (admittedly, limited) experience with Matlab and Psychtoolbox, I’ve always found it to be a little… sensitive. What I mean is that whenever I’ve tried to transfer a (working) program onto another computer, I’ve generally run into trouble. Either the timing goes to hell, or  a different version of Matlab/Psychtoolbox is needed, or (in the worst cases) the program just crashes and needs debugging all over again. I could foresee getting this Matlab code working well on every single students’ laptop would be fraught with issues – some of them might be using OS X, and some might be using various versions of Windows – this is definitely going to cause problems.*

Somewhat counterintuitively therefore, I decided that the easiest thing to do was start from scratch and re-create the experiment using something else entirely. Since PsychoPy is a) entirely free, b) cross-platform (meaning it should work on any OS), and c) something I’d been meaning to look at seriously for a while anyway, it seemed like a good idea to try it out.

I’m happy to report it’s generally worked out pretty well. Despite being a complete novice with PsychoPy, and indeed the Python programming language, I managed to knock something reasonably decent together within a few hours. At times it was frustrating, but that’s always the case when programming experiments (at least, it’s always the case for a pretty rubbish programmer like me, anyway).

So, there are two separate modules to PsychoPy – the ‘Builder’ and the ‘Coder’. Since I’m a complete novice with Python, I steered clear of the Coder view, and pretty much used the Builder, which is a really nice graphical interface where experiments can be built up from modules (or ‘routines’) and flow parameters (i.e. ‘loop through X number of trials’) can be added. Here’s a view of the Builder with the main components labelled (clicky for bigness):

At the bottom is the Flow panel, where you add new routines or loops into your program. The large main Routine panel shows a set of tabs (one for each of your routines) where the events that occur in each of the routines can be defined on a timeline-style layout. At the right is a panel containing a list of stimuli (pictures, videos, random-dot-kinematograms, gratings etc.) and response types (keyboard, mouse, rating scales) that can be added to the routines. Once a stimulus or response is added to a routine, a properties box pops up which allows you to modify basic  (e.g. position, size, and colour of text) and some advanced (through the ‘modify everything’ field in some of the dialog boxes) characteristics.

It seems like it would be perfectly possible to build some basic kinds of experiments (e.g. a Stroop task) through the builder without ever having to look at any Python code. However, one of the really powerful features of the Builder interface is the ability to insert custom code snippets (using the ‘code’ component). These can be set to execute at the beginning or end of the experiment, routine, or on every frame. This aspect of the Builder really extends its capabilities and makes it a much more flexible, general-purpose tool. Even though I’m not that familiar with Python syntax, I was fairly easily able to get some if/else functions incorporating random number generation that calculated the amount returned to the investor on a trial, and to use those variables to display post-trial feedback. Clearly a bit of familiarity with the basics of programming logic is important to use these functions though.

This brings me to the Coder view – at any point the ‘Compile Script’ button in the toolbar can be pushed, which opens up the Coder view and displays a script derived from the current Builder view. The experiment can then be run either from the Builder or the Coder. I have to admit, I didn’t quite understand the relationship between the two at first –  I was under the impression that these were two views of the same set of underlying data, and changes in either one would be reflected in the other (a bit like the dual-view mode of HTML editors like Dreamweaver) but it turns out that’s not the case, and in fact, once I thought about it, that would be very difficult to implement with a ‘proper’ compiled language like Python. So, a script can be generated from the Builder, and the experiment can then be run from that script, however, changes made to it can not be propagated back to the Builder view. This means that unless you’re a serious Python ninja, you’re probably going to be doing most of the work in the Builder view. The Coder view is really good for debugging and working out how things fit together though – Python is (rightly) regarded as one of the most easily human-readable languages and if you’ve got a bit of experience with almost any other language, you shouldn’t find it too much of a problem to work out what’s going on.

Another nice feature is the ability of the ‘loop’ functions to read in the data it needs for each repeat of the loop (e.g. condition codes, text to be presented, picture filenames, etc.) from a plain text (comma separated) file or Excel sheet. Column headers in the input file become variables in the program and can then be referenced from other components. Data is also saved by default in the same two file formats – .csv and .xls. Finally, the PsychoPy installation comes with a set of nine pre-built demo experiments which range from the basic (Stroop) to more advanced ones (BART) which involve a few custom code elements.

There’s a couple of features that it doesn’t have which I think would be really useful – in particular in the Builder view it would be great if individual components could be copied and pasted between different routines. I found myself adding in a number of text elements and it was a bit laborious to go through them all and change the font, size, position etc. on each one so they were all the same. Of course ‘proper’ programmers working in the Coder view would be able to copy/paste these things very easily…

So, I like PsychoPy; I really do. I liked it even more when I transferred my program (written on a MacBook Air running OS X 10.8) onto a creaky old Windows XP desktop and it ran absolutely perfectly, first time. Amazing! I’m having a little bit of trouble getting it running well on a Windows Vista laptop (the program runs slowly and has some odd-looking artefacts on some of the pictures) but I’m pretty sure that’s an issue with the drivers for the graphics card and can be relatively easily fixed. Of course, Vista sucks, that could be the reason too.

So, I’d recommend PsychoPy to pretty much anybody – the Builder view makes it easy for novices to get started, and the code components and Coder view means it should keep seasoned code-warriors happy too. Plus, the holy trinity of being totally free, open-source, and cross-platform are huge advantages. I will definitely be using it again in future projects, and recommending it to students who want to learn this kind of thing.

Happy experimenting! TTFN.

*I don’t mean to unduly knock Matlab and/or Psychtoolbox – they’re both fantastically powerful and useful for some applications.

About Matt Wall

I do brains. BRAINZZZZ.

Posted on November 10, 2012, in Commentary, Experimental techniques, Programming, Software, Study Skills and tagged , , , , , , , , . Bookmark the permalink. 14 Comments.

  1. The structure of scripts is simple and intuitive. As a result, new experiments can be written very quickly, and trying to understand a previously written script is easy, even with minimal code comments.

  2. We actually had a major problem with PsychoPy and ‘sensitivity’ between machines as well as other bugs. I really wish we had never wandered away from Presentation, Inquisit etc. OpenSesame is impressive and free (as in for the user)…but I think its development is commercially funded by eyetracking device company, which probably helps. Still, PsychoPy was impressive given that it is an all volunteer effort and it seems to work perfectly fine for many things.

    • Very interesting comment – thanks. If you don’t mind, I’d be very interested in hearing more about the issues you had with PsychoPy – can you give us any more information?

    • Just a quick comment to (perhaps) clarify things regarding performance. Assuming that by ‘sensitivity’ you mean that PsychoPy runs much more smoothly on one system than another (more so than performance would vary for other packages), this likely has to do with how PsychoPy generates stimuli, by relying heavily on the graphics card.

      This means that on some systems performance is poor, *but* … it also means that PsychoPy can do things that, as far as I know, no other stimulus presentation package can. For example, with PsychoPy you can generate drifting gratings on the fly, etc.

      For this reason, PsychoPy is not the default back-end in OpenSesame (of which I’m the developer), but I nevertheless recommended it to the more advanced users who require the functionality offered by PsychoPy (in which case you can use the PsychoPy libraries from within OpenSesame, more-or-less as you can from the PsychoPy builder view).

      • Thanks for the clarification Sebastian – very helpful, and good to know that PsychoPy requires a decent graphics card. I’m planning on spending some more time looking at OpenSesame at some point, and I’m sure I’ll write something about it too, when I get a chance…

    • @st Sorry to hear that you had problems with PsychoPy. Certainly sorry to hear they were bad enough to make you regret switching – that honestly isn’t an impression I’ve heard from many people.
      There is a mailing list where the developers try to fix any genuine bugs that are found, and generally provide advice. I hope and believe we’re continuing to make improvements as people get stuck.

      [Thanks Matt for the review]

  3. Nicely written review. There is a lot to like about PsychoPy, and the Builder is a really nice tool especially to get people started.

    As the main developer of Psychtoolbox, i want to clarify a few things though. First, at least on Linux and OSX you don’t need Matlab to run Psychtoolbox. It also works perfectly fine with GNU/Octave, a mature, free and open-source Matlab replacement. We used to support Octave on Windows as well, but stopped that for the time being due to apparent lack of interest from our users on that platform. Second, Psychtoolbox, to my knowledge takes more advantage from modern graphics cards than any other toolkit i’m aware of. Last time i checked even way more so than PsychoPy. As such it really benefits from modern graphics hardware, although it should still work reasonably well with 10 years old graphics cards, although it would lose much of the really interesting functionality.

    The sensitivity to different systems may look like a disadvantage, but i consider it an important feature. By default, Psychtoolbox performs rather extensive tests of your system at the start of each session and during the session, to spot possible flaws in your system. It can workaround or compensate for certain flaws. The idea though is that it is better to abort a session if flaky equipment is detected and give you pointers on how to fix your setup, than to just continue without warnings and let you collect confounded data, where you may measure mostly artifacts from your stimulus presentation or response collection equipment. So it is more sensitive to bad equipment, but this is usually not due to software bugs in Psychtoolbox, but simply because sadly a large fraction of the computing equipment out there, especially operating systems and device drivers, is really somewhat broken and of questionable or insufficient quality for research. You can also disable such correctness tests to get the software running on broken equipment, e.g., for teaching students, running inside Virtual Machines, etc., where research grade precision and robustness doesn’t matter much.


    • Hi Mario,

      Many thanks for the comments – really helpful. I wasn’t aware that Psychtoolbox was supported on Octave, so thanks for that. Also good to know that some of my experiences with psychtoolbox come from it being ‘clever’ and aborting sessions because of hardware limitations – that’s actually pretty great.

      Thanks again,


  4. Hey Matt, i am planning something quite similar with open sesame. To install it on the students laptops.
    Could you send me some parts of your script, which might be helpful?
    I am thinking about the screen resolution. How did you fix it, to show the same picture in the middle of the screen on each laptop (assuming different resolutions and screen sizes)?
    How did you code the logfile (and file with the stored stimuli) ? Did you have a code, which defines that the logfile is a file which is to be found in the same path as the experiment is saved?

    • Hi,

      I’m afraid I know very little about OpenSesame, so may not be of much help. In PsychoPy the default units are basically proportions of the screen size, so if you set the picture size to be x=0.5 y=0.5 it will always cover the same proportion of the screen, no matter what the actual screen size and resolution is. Maybe see if Open Sesame has some similar kind of feature?
      For the logfile, psychopy automatically creates a ~/data folder wherever the main experimental code is and save the logs in there.

  1. Pingback: Open-Source software for psychology and neuroscience | Computing for Psychologists

  2. Pingback: How to hack conditional branching in the PsychoPy builder | Computing for Psychologists

  3. Pingback: A new paper on timing errors in experimental software | Computing for Psychologists

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 )

Google photo

You are commenting using your Google 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 )

Connecting to %s

<span>%d</span> bloggers like this: