[Pkg-exppsy-maintainers] PyEPL: Let's move on
Per B. Sederberg
persed at princeton.edu
Mon Apr 28 18:56:56 UTC 2008
Hello again folks:
So, I started the refactoring of pyepl this weekend. It's currently
in a broken state, but it's gonna be MUCH better when I'm done. You
can check it out in the per/refactor branch on alioth. Please help
out if you like or simply give comments and suggestions if you have
time.
At the moment I don't see any reason to merge in / make use of pyglet
or psychopy, mainly because we already provide almost the exact same
interface to pygame surfaces that psychopy does and pyglet is not
ready for full-on primetime (no joystick support, no gamma correction,
no audio recording, ...). When it is, it may be worth switching to
it.
After spending a chunk of time with pyepl, I was reminded about all
the things that make it great. At the top of the list is the idea of
tracks, but it really has some nice features in there that no other
package has (primarily these features all help with coding experiments
properly, which is what we do.)
Obviously, it's lacking the visual stimulus generation that psychopy
has, but I think it will be pretty easy to add this in. It may even
be possible to make use of the psychopy classes directly.
Finally, there is very little, if anything, keeping pyepl from working
on windows. After I get the base level of the refactorization done, I
welcome other coders to step up and start trying this out to see what
changes we'll have to make (I'm happy to provide support for this
process.)
I also have tons of ideas to make pyepl even cooler, which will help
broaden the user-base. For one, I'd like to see if we can get
implicit use of PresentationClocks so that everyone can benefit more
easily from more-precise timing.
Best,
Per
On Mon, Apr 21, 2008 at 11:20 AM, Per B. Sederberg <persed at princeton.edu> wrote:
> 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
> >
>
More information about the Pkg-exppsy-maintainers
mailing list