Regular readers will know that I’m a big fan of PsychoPy, which (for non-regular readers; *tsk*) is a piece of free, open-source software for designing and programming experiments, built on the Python language. I’ve been using it a lot recently, and I’m happy to report my initial ardour for it is still lambently undimmed.
The PsychoPy ‘builder’ interface (a generally brilliant, friendly, GUI front-end) does have one pretty substantial drawback though; it doesn’t support conditional branching. In programming logic, a ‘branch’ is a point in a program which causes the computer to start executing a different set of instructions. A ‘conditional branch’ is where the computer decides what to do out of two of more alternatives (i.e. which branch to follow) based on some value or ‘condition’. Essentially the program says, ‘if A is true: do X, otherwise (or ‘else’ in programming jargon) if B is true; do Y’. One common use of conditional branching in psychology experiments is to repeat trials that the subject got incorrect; for instance, one might want one’s subjects to achieve 90% correct on a block of trials before they continue to the next one, so the program would have something in it which said ‘if (correct trials > 90%); then continue to the next block, else if (correct trials < 90%); repeat the incorrect trials’.
At the bottom of the PsychoPy builder is a time-line graphic (the ‘flow panel’) which shows the parts of the experiment:
The experiment proceeds from left to right, and each part of the flow panel is executed in turn. The loops around parts of the flow panel indicate that the bits inside the loops are run multiple times (i.e. they’re the trial blocks). This is an extremely powerful interface, but there’s no option to ‘skip’ part of the flow diagram – everything is run in the order in which it appears from left-to-right.
This is a slight issue for programming fMRI experiments that use block-designs. In block-design experiments, typically two (or more) blocks of about 15-20 seconds are alternated. They might be a ‘rest’ block (no stimuli) alternated with a visual stimulus, or two different kinds of stimuli, say, household objects vs. faces. For a simple two-condition-alternating experiment one could just produce routines for two conditions, and throw a loop around them for as many repeats as needed. The problem arises when there are more than two block-types in your experiment, and you want to randomise them (i.e. have a sequence which goes ABCBCACAB…etc.). There’s no easy way of doing this in the builder. In an experiment lasting 10 minutes one might have 40 15-second blocks, and the only way to produce the (psuedo-random) sequence you want is with 40 separate elements in the flow panel that all executed one-by-one (with no loops). Building such a task would be very tedious, and more importantly, crashingly inelegant. Furthermore, you probably wouldn’t want to use the same sequence for every participant, so you’d have to laboriously build different versions with different sequences of the blocks. There’s a good reason for why this kind of functionality hasn’t been implemented; it would make the builder interface much more complicated and the PsychoPy developers are (rightly) concerned with keeping the builder as clean and simple as possible.
Fortunately, there’s an easy little hack which was actually suggested by Jon Peirce (and others) on the PsychoPy users forum. You can in fact get PsychoPy to ‘skip’ routines in the flow panel, by the use of loops, and a tiny bit of coding magic. I thought it was worth elaborating the solution on here somewhat, and I even created a simple little demo program which you can download and peruse/modify.
So, this is how it works. I’ve set up my flow panel like this:
So, there are two blocks, each of which have their own loop, a ‘blockSelect’ routine, and a ‘blockSelectLoop’ enclosing the whole thing. The two blocks can contain any kind of (different) stimulus element; one could have pictures, and one could have sounds, for instance – I’ve just put some simple text in each one for demo purposes. The two block-level loops have no condition files associated with them, but in the ‘nReps’ field of their properties box I’ve put a variable ‘nRepsblock1′ for block1 and ‘nRepsblock2′ for block2. This tells the program how many times to go around that loop. The values of these variables are set by the blockSelect routine which contains a code element, which looks like this:
The full code in the ‘Begin Routine’ box above is this:
if selectBlock==1: nRepsblock1=1 nRepsblock2=0 elif selectBlock==2: nRepsblock1=0 nRepsblock2=1
This is a conditional branching statement which says ‘if selectBlock=1, do X, else if selectBlock=2, do Y’. The variable ‘selectBlock’ is derived from the conditions file (an excel workbook) for the blockSelectLoop, which is very simple and looks like this:
So, at the beginning of the experiment I define the two variables for the number of repetitions for the two blocks, then on every go around the big blockSelectLoop, the code in the blockSelect routine sets one of the number of repetitions of each of the small block-level loops to 0, and the other to 1. Setting the number of repetitions for a loop to 0 basically means ‘skip that loop’, so one is always skipped, and the other one is always executed. The blockSelectLoop sequentially executes the conditions in the excel file, so the upshot is that this program runs block1, then block2, then block1 again, then block2 again. Now all I have to do if I want to create a different sequence of blocks is to edit the column in the conditions excel file, to produce any kind of sequence I want.
Hopefully it should be clear how to extend this very simple example to use three (or more) block/trial types. I’ve actually used this technique to program a rapid event-related experiment based on this paper, that includes about 10 different trial types, randomly presented, and it works well. I also hope that this little program is a good example of what can be achieved by using code-snippets in the builder interface; this is a tremendously powerful feature, and really extends the capabilities of the builder well beyond what’s achievable through the GUI. It’s a really good halfway step between relying completely on the builder GUI and the scaryness of working with ‘raw’ python code in the coder interface too.
If you want to download this code, run it yourself and poke it with a stick a little bit, I’ve made it available to download as a zip file with everything you need here. Annoyingly, WordPress doesn’t allow the upload of zip files to its blogs, so I had to change the file extension to .pdf; just download (right-click the link and ‘Save link as…’) and then rename the .pdf bit to .zip and it should work fine. Of course, you’ll also need to have PsychoPy installed as well. Your mileage may vary, any disasters that occur as a result of you using this program are your own fault, etc. etc. blah blah.
Happy coding! TTFN.
This may not look like much, but it’s actually pretty cool. It’s a new five-button response-box being built for our MRI scanner by one of the technicians where I work. The cool thing is that the main chassis has been custom-designed, and then fabricated using a polyethylene-extruding 3D printer. The micro-switches for the four fingers and thumb and the wired connections for each have obviously been added afterwards.
3D printing in plastic is a great way of creating hardware for use in the MRI environment, as, well… it’s plastic, and it can create almost any kind of structure you can think of. We sometimes need to build custom bits of hardware for use in some of our experiments, and previously we’d usually build things by cutting plastic sheets or blocks to the required shape, and holding them together with plastic screws. Using a 3D-printer means we can produce solid objects which are much stronger and more robust, and they can be produced much more quickly and easily too. I love living in the future.
I just accidentally made a kind-of version of the classic hollow-face illusion, using an anatomical MRI scan of my own head and Osirix. I exported a movie in Osirix, saved the movie as an image sequence using Quicktime, and then assembled it into an animated GIF using GIMP.
This is a maximum intensity projection, and because of the way MIPs work, it appears that the head is rotating 180 degrees to the left, and then the direction switches and it rotates back 180 degrees to the right. In actual fact, the image is rotating constantly in one direction, as can be seen by looking at the cube on the top left which cycles through L (Left), P (Posterior), R (Right), and A (Anterior). It’s not really a hollow-face illusion as the effect is pretty much an artefact of the MIP, but still, I thought it was cool.
…is really, really brilliant, and you should all go and look at it. That is all.
Since I’ve switched to using PsychoPy for programming my behavioural and fMRI experiments (and if you spend time coding experiments, I strongly suggest you check it out too, it’s brilliant) I’ve been slowly getting up to speed with the Python programming language and syntax. Even though the PsychoPy GUI ‘Builder’ interface is very powerful and user-friendly, one inevitably needs to start learning to use a bit of code in order to get the best out of the system.
Before, when people occasionally asked me questions like “What programming language should I learn?” I used to give a somewhat vague answer, and say that it depended largely on what exactly they wanted to achieve. Nowadays, I’m happy to recommend that people learn Python, for practically any purpose. There are an incredible number of libraries available that enable you to do almost anything with it, and it’s flexible and powerful enough to fit a wide variety of use cases. Many people are now using it as a free alternative to Matlab, and even using it for ‘standard’ statistical analyses too. The syntax is incredibly straight-forward and sensible; even if an individual then goes on to use a different language, I think Python is a great place to start with programming for a novice. Python seems to have been rapidly adopted by scientists, and there are some terrific resources out there for learning Python in general, and its scientific applications in particular.
For those getting started there are a number of good introductory resources. This ‘Crash Course in Python for Scientists’ is a great and fairly brief introduction which starts from first principles and doesn’t assume any prior knowledge. ‘A Non-Programmers Tutorial for Python 2.6′ is similarly introductory, but covers a bit more material. ‘Learn Python the Hard Way’ is also a well-regarded introductory course which is free to view online, but has a paid option ($29.95) which gives you access to additional PDFs and video material. The ‘official’ Python documentation is also pretty useful, and very comprehensive, and starts off at a basic level. Yet another good option is Google’s Python Classes.
For those who prefer a more interactive experience, CodeAcademy has a fantastic set of interactive tutorials which guide you through from the complete beginning, up to fairly advanced topics. PythonMonk and TryPython.org also have similar systems, and all three are completely free to access – well worth checking out.
For Neuroimagers, there are some interesting Python tools out there, or currently under development. The NIPY (Neuroimaging in Python) community site is well worth a browse. Most interestingly (to me, anyway) is the nipype package, which is a tool that provides a standard interface and workflow for several fMRI analysis packages (FSL, SPM and FreeSurfer) and facilitates interaction between them – very cool. fMRI people might also be very interested in the PyMVPA project which has implemented various Multivariate Pattern Analysis algorithms.
People who want to do some 3D programming for game-like interfaces or experimental tasks will also want to check out VPython (“3D Programming for ordinary mortals”!).
Finally, those readers who are invested in the Apple ecosystem and own an iPhone/iPad will definitely want to check out Pythonista - a full featured development environment for iOS, with a lot of cool features, including exporting directly to XCode (thanks to @aechase for pointing this one out on Twitter). There looks to be a similar app called QPython for Android, though it’s probably not as full-featured; if you’re an Android user, you’re probably fairly used to dealing with that kind of disappointment though. ;o)
Anything I’ve missed? Let me know in the comments and I’ll update the post.
When I was an undergraduate student, email was still not widely used, and the idea of emailing a lecturer or professor would have been quite daunting. Times have changed however, and nowadays most academics deal with a steady stream of emails from students throughout the year. This is a good thing in many ways; it helps to break down barriers between the staff and students and can be a very efficient way to communicate. Unfortunately many students don’t follow some basic rules of general politeness when contacting staff and this leads to faculty members getting irritated, and students receiving witheringly sarcastic responses or links to let me Google that for you.
Here are a few pieces I’ve collected that set out precisely how best to communicate with your advisor, lecturer or professor. First of all, we have a guide from Wellesley College titled How to Email Your Professor, shared on Twitter by Tom Hartley. Tom also went to the bother of conducting a survey about this kind of thing, and presented the results on his blog. He highlights some interesting cultural differences, particularly between the UK and the US – well worth reading through.
I won’t bother repeating much of what these excellent sources suggest, except to say that the common threads through them all seem to be:
1) Be polite, and relatively formal (at least at first).
2) Don’t ask stupid questions.
3) Don’t make stupid (i.e. any) spelling and grammar mistakes.
4) For the love of all that is good and holy, get the name and title of the person you’re emailing correct.
How hard can that be, eh?
Somebody asked me about using a voice key device the other day, and I realised it’s not something I’d ever addressed on here. A voice key is often used in experiments where you need to obtain a vocal response time, for instance in a vocal Stroop experiment, or a picture-naming task.
There are broadly two ways of doing this. The first is easy, but expensive, and not very good. The second is time-consuming, but cheap and very reliable.
The first method involves using a bit of dedicated hardware, essentially a microphone pre-amp, which detects the onset of a vocal response, and sends out a signal when it occurs. The Cedrus SV-1 device pictured above is a good example. This is easy, because you have all your vocal reaction times logged for you, but not totally reliable because you have to pre-set a loudness threshold for the box, and it might miss some responses, if the person just talks quietly, or there’s some unexpected background noise. It should be relatively simple to get whatever stimulus software you’re running to recognise the input from the device and log it as a response.
The other way is very simple to set up, in that you just plug a microphone into the sound card of your stimulus computer and record the vocal responses on each trial as .wav files. Stimulus software like PsychoPy can do this very easily. The downside to this is that you then have to take those sound files and examine them in some way in order to get the reaction time data out – this could mean literally examining the waveforms for each trial in a sound editor (such as Audacity), putting markers on the start of the speech manually, and calculating vocal RTs relative to the start of the file/trial. This is very reliable and precise, but obviously reasonably time-consuming. Manually putting markers on sound files is still the ‘gold standard’ for voice-onset reaction times. Ideally, you should get someone else to do this for you, so they’ll be ‘blind’ to which trials are which, and unbiased in calculating the reaction times. You can also possibly automate the process using a bit of software called SayWhen (paper here).
Which method is best depends largely on the number of trials you have in your experiment. The second method is definitely superior (and cheaper, easier to set up) but if you have eleventy-billion trials in your experiment, manually examining them all post hoc may not be very practical, and a more automatic solution might be worthwhile. If you were really clever you could try and do both at once – have two computers set up, the first running the stimulus program, and the second recording the voice responses, but also running a bit of code that signals the first computer when it detects a voice onset. Might be tricky to set up and get working, but once it was, you’d have all your RTs logged automatically on the first computer, plus the .wav files recorded on the second for post hoc analysis/data-cleaning/error-checking etc. if necessary.
Two researchers have pointed out in the comments, that a system for automatically generating response times from sound-files already exists, called CheckVocal. It seems to be designed to work with the DMDX experimental programming system (free software that uses Microsoft’s DirectX system to present stimuli). Not sure if it’ll work with other systems or not, but worth looking at… Have also added the information to my Links page.
So, another academic year is about to hove into view over the horizon, and what better time to take stock of your situation, make sure your gear is fit for purpose, and think about levelling-up your geek skills to cope with the rigours of the next year of academic life. If you need any hardware, Engadget’s Back to School review guides are a great place to start, and have reviews of all kinds of things from smartphones to gaming systems, all arranged helpfully in several price categories.
If you really want to be ahead of the game this year though, you’ll need to put in a bit of extra time and effort, and learn some new skills. Here are my recommendations for what computing skills psychology students should be learning, for each year of a standard UK BSc in Psychology.*
If you’re starting your 1st year…
A big part of the first year is about learning basic skills like academic writing, synthesising information, referencing etc. Take a look at my computer skills checklist for psychology students and see how you measure up. Then, the first thing you need to do, on day one, is start using a reference manager. This is an application that will help you organise journal articles and other important sources for your whole degree, and will even do your essay referencing for you. I like Mendeley, but Zotero is really good as well. Both are totally free. Download one of them right now. This is honestly the best bit of advice I can possibly give to any student. Do it. I just can’t emphasise this enough. Really. OK. Moving on.
Next you need to register for a Google account, if you don’t have one already. Here’s why. Then use your new Google username to sign up for Feedly and start following some psychology and neuroscience blogs. Here and here are some good lists to get you started. If you’re a real social-media fiend, sign up for Twitter and start following some of these people.
You may want to use the 5GB of free storage you get with Google Drive as a cloud back-up space for important documents, or you may want to sign up for a Dropbox account as well. Use one or the other, or preferably both, because none of your data is safe. Ever.
If you’re really keen and want to learn some general skills that will likely help you out in the future, learn how to create a website with WordPress or Github Pages. Or maybe download Gimp and get busy with learning some picture editing.
If you’re starting your 2nd year…
This is when things get more serious and you probably can’t expect to turn up to tutorials with an epically massive hangover and still understand everything that’s going on. Similarly, you need to step it up a level with the geekery as well.
You probably learned some SPSS in your statistics course in the first year. That’s fine, but you probably don’t have a licence that allows you to play with it on your own computer. PSPP is the answer – it’s a free application that’s made to look and work just like SPSS – it even runs SPSS syntax code. Awesomes. Speaking of which, if you’re not using the syntax capabilities of SPSS and doing it all through the GUI, you’re doing it wrong.
If you really want to impress, you’ll start using R for your lab reports. The seriously hardcore will just use the base R package, but don’t feel bad if you want to use R-Commander or Deducer to make life a bit easier. Start with the tutorials here.
If you’re starting your 3rd year…
This is the year when you’ll probably have to do either a dissertation, a research project, or maybe both. If you’re not using a reference manager already, trying to do a dissertation without one is utter lunacy – start now.
For your research project, try and do as much of it as you can yourself. If you’re doing some kind of survey project, think about doing it online using Google Forms, or LimeSurvey. If you’re doing a computer-based task, then try and program it yourself using PsychoPy. Nothing will impress your project supervisor more than if you volunteer to do the task/survey set-up yourself. Then of course you can analyse the data using the mad statz skillz you learned in your second year. Make some pretty looking figures for your final report using the free, open-source Veusz.
Learning this stuff might all sound like a lot to ask when you also have essays to write, tutorials to prepare for, and parties to attend. However, all these things are really valuable CV-boosting skills which might come to be invaluable after you graduate. If you want to continue studying at Masters or PhD level, potential supervisors will be looking for applicants with these kinds of skills, and solid computer knowledge can also help to distinguish you from all the other psychology graduates when applying for ‘normal’ jobs too. It really is the best thing you can learn, aside from your course material, naturally.
Have I missed anything important? Let me know in the comments!
* I realise US colleges and other countries have a different structure, but I think these recommendations will still broadly apply.
First up is a new (to me, anyway) scientific plotting package called Veusz. It’s written in Python, is completely free and open-source, works with any OS, and basically looks pretty useful. I’ve been using Prism for a while now, but I’ll definitely try out Veusz next time I need to do some plotting – would prefer to use something open-source.
The new statistics software is called Wizard, and is unfortunately a paid application, and just developed for Macs. If you’re dissatisfied with SPSS (and let’s be honest, who isn’t?) it might be worth the $79 price though. Haven’t tried it out yet personally, but it looks really, really nice in terms of the interface, and seems fairly comprehensive in terms of features as well. Definitely one to think about for Mac users.
Next up is a new reference manager called Paperpile. I’m a big fan of Mendeley, but some of Paperpile’s features are pretty attractive – it lives as a Chrome extension, and uses Google Drive for online storage of the PDFs. Pretty nice. Unfortunately it’s still in a private Beta phase and will cost $29/per year when it’s released.
I was thinking about a new web-page recently, and solicited opinions for which was the current best build-me-a-free-website service. The extremely helpful @Nonmonotonix suggested using Github Pages to both design and host sites – looks like an excellent system. He even wrote a set of instructions on his blog here, for how to get started with Github pages. Another good suggestion was something called Bootstrap, which has the promising tagline “By nerds, for nerds.”
Lastly, a couple of packages for neuroimagers. I’ve just been made aware of a really good collaborative, open-source software project for the analysis of EEG/MEG data – called BrainStorm. Looks like a very capable suite of tools. I’ve also just come across the PyMVPA project, which does exactly what it says on the tin – Multivariate Pattern Analysis in Python. Nice.
All of these links, and many, many more can of course be found on my newly-updated Links page.
It’s always exciting when you find a new piece of cool software to play with, and even more so when what you’ve found is totally free, open-source, and available on all platforms. So it is with MakeHuman - an utterly awesome bit of kit. I wrote a piece before about FaceGen, which is also pretty cool, but MakeHuman takes it to the next level, by modelling all kinds of body characteristics as well as faces, and, of course, doing it all for free.
I’ve just downloaded it and played with it for a few minutes, but I’m already impressed by the range of options available. Through a very simple slider and radio-button based interface you have very fine control over all kinds of variables, including gender, weight, age, height, and many more, with endless fine tweak-ability possible of body and face if you dig through the options. There are also basic libraries of clothes and poses included. Here’s a well, a human, I made in just a couple of minutes:
And here’s a close-up of the face, after I added some hair and gave him a nasty expression:
Pretty cool indeed. This could potentially be a massively useful tool for people interested in face/body perception – using this, one could generate a large number of highly-controlled experimental stimuli that just differ in one aspect (say, weight, or race… whatever) very easily and quickly. Download it and have a play around!