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

[Per B. Sederberg]

Howdy Michael et al.!

Thanks for starting this thread!  See my thoughts below...

On Mon, Apr 21, 2008 at 5:21 AM, Michael Hanke <michael.hanke at gmail.com> wrote:
> 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?
>

This is the main repository, I'm the only person who has been doing
any work on it, but I have not had any time recently.  Obviously,
there's much to be done.

>  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) ;-)
>

There are no current dependencies that are not Windows compatible,
however, there is some code in pyepl that only looks for linux vs.
OSX, so those parts will have to be fixed.  I don't have a windows
machine to test this, but I'm happy to work with anyone to work
through it all.

As for the install, that should certainly be a long-term goal (we do
the same for OSX), but the first stage may be much easier if we use
py2exe.  If we can get a windows machine to run pyepl, then it will be
possible to make a single executable for each experiment that includes
all the pre-compiled dependencies as part of the executable. I have
not tried this, but it is something to keep on the table.

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

Obviously timing is key and we have worked hard to ensure good timing
in pyepl via the PresentationClock class.  We also keep track of
screen refreshes (if the video card/platform supports it) so that you
know when a stimuli is visually presented.  On OSX, we give the
experiment realtime priority, which makes timing even better.  I think
I'll be able to do a similar thing on linux now that I run linux all
the time.

I would love to have some core programs that people could use to test
timing on their machines.  We should definitely talk about what those
should consist of.

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

The foundation for external interfaces is there, but right now almost
every external device does need some form of additional code.

All your ideas here sound great.  We can certainly make that fMRITrack
very quickly.  I have loads of code that already does this sort of
thing in my experiments, but it would be much better as a track.

>
>  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.
>
>
This is absolutely a must to make pyepl a viable option for !
VisionEgg is good, but PsychoPy may be even better (it's the port of
the PsychToolbox to python.)  It would be great to have the stimulus
generation capabilities of either of these two combined with the
experiment structure provided by pyepl.

>
>  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.
>
>
I started such a thing, but then quickly realized that it was a larger
task than I had hoped.  That's where I started wondering whether to
start with a new codebase and pull in the pieces from pyepl.  In
general, the likelihood of me being able to do this restructuring over
the next month is very low, but you never know...  It might actually
be relatively easy, but it would surely break all current experiments.

On a different note, making a new project might be good because then I
could be the copyright holder.  Right now Mike Kahana holds the
copyright to pyepl.

I look forward to more conversations about all this :)

Latro,
P

>
>  Cheers,
>
>  Michael
>
>
>  --
>  GPG key:  1024D/3144BE0F Michael Hanke
>  http://apsy.gse.uni-magdeburg.de/hanke
>  ICQ: 48230050
>
>  _______________________________________________
>  Pkg-exppsy-maintainers mailing list
>  Pkg-exppsy-maintainers at lists.alioth.debian.org
>  http://lists.alioth.debian.org/mailman/listinfo/pkg-exppsy-maintainers
>