Submitting PEPs

Development
1

Hello,

Can anyone submit PEPs (PsychoPy Enhancement Proposals) to the GitHub Wiki?

  • mdc
2

The only one we have there (which hasn’t moved much!) resulted from quite a bit of discussion. What are you wanting a PEP about?

3

Hello,

I wanted to submit one for additional colour depth support. I know what’s involved and I feel that posting PEPs might be a good starting point to help coordinate any existing efforts.

4

I expect there is that and lot of Mario Kleiner’s other work in the PsychToolbox which could be borrowed by a combination of cutting and pasting, re-implementing or wrapping C in Python. In the most effortful case, that the PTB only serves as an example of how to implement stuff, without any actual code borrowed, that would still be a great big leg up.

I did build an abstraction layer into the PsychToolbox called ScriptingGlue to make it easy to bind the Psychtoolbox to scripting languages other than MATLAB. It would probably work well for kindred languages such as SciLab, also even Mathematica (though at it’s heart it’s kind of LISPy), but in the case of Python we would end up with an API startlingly un-Pythonic and neither well-aligned with, nor orthogonal to, PsychoPy.

So, advice is: If you are writing a PEP, first check out the Psychtoolbox for a menu of capabilities with sample code then think of what an API which implements those should look like in Python/PsychoPy. The video driver stuff, particularly timing, CLUTs and higher bit depths would be choice.

Finally, the limiters to adding capabilities are not a lack of planning and PEPs but shortages of programmers willing to donate their free time and of grant funding to sponsor paid programming. Planning is good but writing a PEP will not cause the work to be done. Finding funding would.

best,

Allen

2 Likes
5

I pretty much agree. (Hence PEP1 is still sitting there, although a couple of the pieces of that were implemented). Don’t mean to dampen your enthusiasm though - it doesn’t hurt to write these things and can make more clear how to do it. But Allen’s right that the implementation is the key.

I’ll message you privately about the possibilities around the PTB C-code engine being ported - I’m currently discussing with Mario whether this would be a real possibility if we had the finances to pay for it.

1 Like
6

Thanks for the responses.

I expect there is that and lot of Mario Kleiner’s other work in the PsychToolbox which could be borrowed by a combination of cutting and pasting, re-implementing or wrapping C in Python. In the most effortful case, that the PTB only serves as an example of how to implement stuff, without any actual code borrowed, that would still be a great big leg up.

Looking at PTB might be an excellent start given they’ve encountered most of these issues already. I’m actually quite familiar with CFFI and Cython extending PsychoPy for my own use, however it might make packaging more complicated due to the compiling step (I’m aware CFFI has an ABI, but it has been hit or miss for me).

I did build an abstraction layer into the PsychToolbox called ScriptingGlue to make it easy to bind the Psychtoolbox to scripting languages other than MATLAB. It would probably work well for kindred languages such as SciLab, also even Mathematica (though at it’s heart it’s kind of LISPy), but in the case of Python we would end up with an API startlingly un-Pythonic and neither well-aligned with, nor orthogonal to, PsychoPy.

Very cool, I thought PTB was heavily integrated with MATLAB/Octave making wrapping it’s libraries tricky.

Finally, the limiters to adding capabilities are not a lack of planning and PEPs but shortages of programmers willing to donate their free time and of grant funding to sponsor paid programming. Planning is good but writing a PEP will not cause the work to be done. Finding funding would.

I’m not necessarily using PEPs to advertise the topic and hope someone comes along, rather it’s to state my intentions. Facilitating discussion (is it even worth the effort?), keep track of progress and provide warning about what’s likely to change.

7

Very worthwhile, in my opinion.

On a potentially related note, I have been working on adding support for non 8-bit LUTs (BF: restore gamma functionality with non 8-bit LUTs by djmannion · Pull Request #1626 · psychopy/psychopy · GitHub) that might be related to your plans for high bit-depth support.

1 Like