PsychoPy Vs. PsychtoolBox

[or duek]

Hi,
I know its weird to ask that kind of question here but I'm really
confused.
I want to start programming my Ph.D. experiments using one of those
tools.
While I know Python is easier, and I use a Linux and Open Source
solutions for most of my things, I'm afraid to build a good experiment
that will be unacceptable in the scientific community due to a
relatively unknown tool.
What do you think?
Thank you very much for your comments.

[Jake Westfall]

I don't see why anyone would care what tool you use to build your experiments, as long as the experiments do what you need them to do.

Jake

> Date: Tue, 1 Dec 2009 00:25:40 -0800
> Subject: [psychopy-users] PsychoPy Vs. PsychtoolBox
> From: ord...@gmail.com
> To: psychop...@googlegroups.com

> --
>
> You received this message because you are subscribed to the Google Groups "psychopy-users" group.
> To post to this group, send email to psychop...@googlegroups.com.
> To unsubscribe from this group, send email to psychopy-user...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/psychopy-users?hl=en.
>
>

---

Windows Live Hotmail gives you a free,exclusive gift. Click here to download.

[Jeremy Gray]

Hi Or,

you can easily show that PsychoPy is solid: cite Jon's papers. as a reviewer I would mostly want to know about the degree of quality control that has gone into development, because that really matters. citing the peer reviewed papers goes a long way there. I would not care whether I knew about the tool already.

if reviewers ask for more, you could point to the fact that it was developed for doing psychophysics, which requires a very high degree of control over presentation timing and physical display, and that it is open source (hence many eyes can look at the code and contribute fixes), and has been under active development for several years.

as a reviewer, I would be far more skeptical about a given person's code (their way of setting up their experiment using PP) than PP itself. so when starting out, its probably a very good idea to build in routines to double check your timing and so on. you'll then have data a) to convince yourself you did things right, and b) to convince reviewers that you did things right.

just my .02,

--Jeremy

[Michael MacAskill]

Dear Or,

I agree entirely with Jeremy. Many people use their own custom
programming to run experiments, so in terms of publication, you're
actually ahead by being able to cite Jon's papers to show that you're
using an established system.

As Jeremy says, having a system which ALLOWS you to produce accurate
and precise experiments doesn't mean that one actually WILL. It is
entirely possible to produce non-optimal code which will muck up
timings, or to produce a dissociation between what is displayed and
what is actually recorded as data. Fundamentally, you need to test, re-
test, and test again.

I've just been implementing an fMRI block design in PsychoPy. Each
block should last 27 s. My initial runs showed variability of up to
several hundred milliseconds per block (not crucial from an fMRI
design point of view, but important for measuring reaction times to
the individual events). Now, each block duration is within one screen
refresh of 27 s. The initial problems were due to several factors:
-- running the development code from my laptop (with a 60 Hz internal
screen clock) rather than the dedicated stimulus PC and 100 Hz CRT to
be used on the production version in the lab (although the fMRI runs
will also be at 60 Hz so that was a useful heads-up). 100 Hz refresh
rates are great because you can set all of your experimental timings
in multiples of 10 ms. Code that runs like clockwork on a 100 Hz
screen can show a bit of slippage when runs at other refresh rates,
depending on the way one does timing. e.g. it is possible to display a
stimulus for exactly 100 ms at 100 Hz, but not at 60Hz, where
durations must be multiples of 16.67 ms.
-- issues with synchronising with our eye tracker (understanding that
successive network UDP messages aren't sent in real time on Windows
but are also run on a 100 Hz schedule)
-- and lastly, choosing one of several possible timing schemes that
PsychoPy makes possible. You can count frames, or you can continually
check a timer. You can time individual events, or run an absolute
timer over the course of the experiment to prevent drift.

What reviewers are looking for is evidence that you have given
consideration to performance and quality issues. Where those can't be
controlled, they should be quantified and stated as limits on the
accuracy of results. For example, you may be able to precisely control
the timing of visual presentation of stimuli, but your primary
dependent measure is a keypress on a USB keyboard, the reliability of
which will be the actual limiting factor. Conversely, I've reviewed
papers where people used LCD screens and expected to get accurate
response latencies, not realising that, compared to fast CRT, the
delays (in terms of slow refresh rate but also significant lag in
response (don't believe the marketing specifications)) were a
significant proportion of the expected fast reaction time, which was a
likely contributor to their unusually long saccade latencies.

In essence, reviewers don't care what software you use, only whether
you used it to achieve precise control and whether you are aware of
and accounted for hardware limitations.

In terms of your original question, your task can almost certainly be
implemented in PsychoPy. Open, run, and read a bunch of Jon's examples
from the Demo menu, and you should be most of the way to understanding
how.

Regards,

Michael

--
Michael R. MacAskill, PhD michael....@vanderveer.org.nz
Chief Scientist,
Van der Veer Institute
for Parkinson's & Brain Research

66 Stewart St http://www.vanderveer.org.nz
Christchurch 8011 Ph: +64 3 3786 072
NEW ZEALAND Fax: +64 3 3786 080

[Andrew]

Hi there,

Just to add my two cents: I have used both PsychoPy and PsychToolbox
(PTB), and, although they provide the same stuff, I would recommend
going for PsychoPy.

Why? Well, what may not be obvious about PTB is that the developer is
rather Mac-centric, so unless you are running your experiments in a
recent version of Matlab on a reasonably high-end Apple machine, you
may well run into problems. Specifically, there are a bunch of
keyboard event related functions in PTB that will only work under OSX.
Having done significant development using PTB on windows, I can tell
you that it is quite frustrating when there is a function that does
exactly what you want that you can't use because you're not on a
mac... Also, bear in mind that for PTB you need to have Matlab on all
of the machines you want the experiment to run on (or you need to have
access to the Matlab compiler, which, on windows, doesn't work with
some of the PTB functions), which can be quite restrictive.

That said, if you are working on a Mac, and you have access to Matlab
where you need it, then both PsychoPy and PTB are pleasant enough to
work with, and anything you can produce in one can be produced as
easily, and as robustly, in the other. As I said, I would recommend
using PsychoPy, but that is more for reasons of ease of distribution
and the like.

Anyway, hope that helps.

Andrew

[or duek]

Thank you all for the replies.
Actually I work on a linux laptop but the computer who'll run the
experiments will be either windows or linux based (certainly not a
Mac).
I have a "dream" of using all open source lab (using PsychoPy and R
for the statistical analysis) but a bit afraid to be the first to try
that at my University.
Are there known issues of PsychoPy and Linux?
Did anyone actually published paper using this combination?
Thank you very much.