[Pkg-exppsy-maintainers] PyEPL: Let's move on
Michael Hanke
michael.hanke at gmail.com
Mon Apr 28 19:39:10 UTC 2008
Hi Per,
great news. I'll check it out!
Thanks,
Michael
On Mon, Apr 28, 2008 at 02:56:56PM -0400, Per B. Sederberg wrote:
> 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
> > >
> >
>
> _______________________________________________
> Pkg-exppsy-maintainers mailing list
> Pkg-exppsy-maintainers at lists.alioth.debian.org
> http://lists.alioth.debian.org/mailman/listinfo/pkg-exppsy-maintainers
--
GPG key: 1024D/3144BE0F Michael Hanke
http://apsy.gse.uni-magdeburg.de/hanke
ICQ: 48230050
More information about the Pkg-exppsy-maintainers
mailing list