[Pkg-exppsy-maintainers] PyEPL: Let's move on

[Michael Hanke]

Hi folks,

I just looked into the PyEPL git and saw, that there is no activity
since Jan. If I got it right this should be the main repository now. Or
is there more up-to-date code somewhere else?

In any case, I'd like to proceed with the development. When we last
talked back in October, we basically agreed that PyEPL should become a
lot more modular. Since then I talked with a number of people from
different labs and the message is basically always the same:
{eprime,presentation} should be replaced by something reasonable. Some
people even thought about starting a new thing.

I hope that we do not need something new, but can take PyEPL in its
current shape and use it as a starting point to develop something that
scratches all itches.

I have a few basic requirements for such a softwarei, besides the stuff
that PyEPL already can do. I'm going to list them here and maybe we can
collect a list of problems PyEPL has to solve, so we all know what we
need to develop. Here is my part:


Problem 1: Need to run experiments on Windows.

   I'd love to switch the relevant machines to Linux, but they are not under
   my control. Moreover, I guess there are plenty of reasons why people want
   to use Windows. Especially for those switching from Win/Presentation to
   PyEPL the transition will be a lot easier, if they change one piece
   at a time. But even if I need to finally run experiments on win, I still
   want to develop stuff on my linux desktop (to stay on save ground for
   as long as possible).

Proposed solution 1:

   We should provide a binary installer for win32, that comes with
   everything that is required (perhaps without python itself). To give
   people the experience they expect on Windows
   (click-click-next-next-next-finish) ;-)


Problem 2: Timing

   People always ask about timing first. Although a lot of experiments
   do not have strong requirements about timing -- everybody want to
   have the best possible timing.

Proposed solution 2:

   We should have a test battery that tells people how accurate their
   timing is. Most likely this requires some extra hardware, but we
   still should provide that code. Moreover, we should start collecting
   data about timing quantification on several platforms (linux kernels
   and configurations, win, mac (different versions), maybe also video
   card vendors and driver situation). Basically covering all the first
   five minute questions everybody will ask.


Problem 3: External IO interfaces

   PyEPL should be able to talk with some IO hardware, eg to catch TTL
   trigger signals or talk to stuff via network (eg. eye-tracking
   devices).

Proposed solution 2:

   Most likely there is no truely generic way to implement all external IO.
   So maybe each platform has to have its own. Additionally we should
   evaluate stuff like pylink
   (http://www.eyelinkinfo.com/mount_software.php#Python) which might
   take away some pain when doing complex interfacing.
   For fMRI, we should probably have an fMRITrack that can be configured
   to catch a variety of trigger signals, properly logs them and can be
   used to trigger some actions(eg. do this trial when you get the 52
   pulse...).


Problem 3: Stimulus generation

   In comparison to VisionEgg, PyEPL is quite poor when it comes to
   stimulus generation (although VisionEgg is probably a little dead
   right now ;-). However, I know that it is possible. I used direct
   drawing on the pygame surfaces in the past, but this does not seem to
   be officially supported, as I had to dig deep into PyEPL to figure
   out how to use it.

   If you look at
   http://www.neurobs.com/nbs_online/presentation/visgen_toolkit

   others consider this useful as well ;-) Not to mention the
   PsychToolbox... Which I guess is actually the one system we should
   aim to replace, as EPrime and Presentation are crap by design.

Proposed solution:

   Provide a nice 'official' interface to dock the wealth of python
   packages dealing with graphics into PyEPL. And of course a little
   library of standard stimuli, maybe we can steal most of them from
   visionegg.



So far for now. I hope we can compile/discuss the full list in the near future.

To really start developing I think it might be best, if someone familiar
with the whole codebase (Per?) identifies the PyEPL core, creates a
branch in git and strips the core from all (optional) modules, deps and
heritage, with the goal to make it easier for people like me to grasp
the inner structure of PyEPL and hopefully come up with a more modular
design.



Cheers,

Michael


-- 
GPG key:  1024D/3144BE0F Michael Hanke
http://apsy.gse.uni-magdeburg.de/hanke
ICQ: 48230050