Hello, I am confused about PsycoPy and Apple Silicon. For what I understand, PsychoPy still uses Rosetta and is compiled for Intel architecture, which makes it less than optimal for experiments with Apple current machines.
would it be possible to know which parts of PsychoPy are dependent on the translation? all of it? or only the graphical interface, and the Python environment is native?
is there any roadmap for PsychoPy being native.
Thanks and apologies if the question is elementary but I have not find a discussion in the forum. I did find the github repository to compile natively, but I gather the project is still far from being completed, and is not hosted by PsychoPy directly if I understand well.
I donāt know anything about Silicon / Rosetta but it sounds like you have some insight into why Mac users struggle so much with PsychoPy.
PsychoPy is open source, hosted on gitlab.com at https://github.com/psychopy/psychopy. Anyone can contribute to the repository but all pull requests are checked / authorised by one of the core developers.
I donāt understand the rest of your questions. PsychoPy is a combination of both libraries and a GUI. There is also a companion open source PsychoJS library at https://github.com/psychopy/psychojs and a closed source server https://pavlovia.org/.
PsychoPy is a product rather than a company. The company itself is Open Science Tools which is a social enterprise. There is no ācompletionā condition for PsychoPy as a project. It will keep evolving for as long as it exists.
Thank you for your prompt answer. I understand about PsychoPy being open source and being hosted on Gitlab. I also understand that it is a quite complex project (that makes complete sense). It is not the case that an executable which has a GUI as well as a runtime written for Python necessarily uses Rosetta for both. The fundamental part is of course the runtime part. I wanted to know, if somebody has a good grip on the code, if all the parts of PsychoPy use Rosetta or only the GUI.
I also understand how open source projects go, and about there not being ācompletionā conditions. Nevertheless any project has some developing guidelines and the question is if there is any effort already going on or intention to develop a native version for the Apple Silicon architecture. Native Python versions exist, and so this is in principle feasible, but I donāt speak with competence here, hence the question.
My tests on the M1-M3 machines for timing precision (pictures and movies is my focus) give quite good results, but also some odd behaviors, especially when trying to program frame-by-frame. I suspect part of the problem may be due to the use of non-native Python versions, hence the question.
PsychoPy code itself is fine (both the gui code and the underlying lib) for mac silicon, but not all the dependencies are compatible.
The main one that is currently a flat ānoā for compiling on mac silicon is psychtoolbox. Thatās important if you want good timing for your audio stimuli/recordings but if you remove that as a dependency and just use sounddevice for audio playback then youāll be fine.
The second one, which is less often needed, is the pytables library, which is used by iohub to stream high-bitrate data to an hdf5 file (e.g. 2kHz eyetracking data). update: Iāve just tried installing that on my M2 macbook and it appears to have worked so maybe that oneās solved
Regarding testing of frame rates, Iāve seen the same Iāve seen the same incredibly variable frame times and discussed here but I donāt think this is anything to do with Arm chips or Rosetta. My belief is that this is caused by MacOS providing variable frame rates. But if you have insights into this then Iām keen to know them
Iāve just built an installation on native arm-architecture Python 3.10 of everything except for psychtoolbox lib, on an M1 running MacOS Ventura
I was able to succesfully launched the app and run the timing demo in Coder view and it gave me the following. I think this agrees with my suggestion above that the issue is with MacOS not with the use of intel/arm architecture
The key points to that timing graph, by the way, are:
the frames seemingly alternate between 4 ms and 12 ms
I believe the actual frame rate of the screen (MacBook Pro built-in screen) was 60 Hz, so I think weāre seeing 2 āvirtualā frames here for every 1 actual frame
Thank you for your answers. I need to organize what I did and think a bit about your values. But if you wanted to make me feel better, if you could make the native build available, I could verify if I have any change on my end. Currently, unfortunately, I have no time to see the code and build it myself.
I do not want to spam the list with info that may not be relevant, but concretely, what I need to do is to 1. understand the temporal relations between a trigger (serial out) and the appearance of a first frame onscreen, and 2. understand to what extent the temporal properties of an image are respected (e.g., stay on screen as much as I want).
What I saw so far is that for what I understand, at least on the architecture I am testing (I am with Sonoma), the win.flip command is not blocking, so that itās impossible to have a complete frame synchronization (thatās not crucial for me but surely unwelcome).
I seem to recall that in the old Quartz (I come from a very old code and program, and I am exploring to what extent I can get rid of it in favor of PsychoPy) there was no way to write on a video card buffer directly, and you had to implement a callback in your code to know when to send an image to the buffer. If the underlying architecture is similar, and the flip is not blocking, then you canāt get any better than have a bimodal distribution of the frames sent to the monitor (and the standard deviation cannot be reduced to 1 ms), assuming 2 buffers. (Also, aside, I find that PsychoPy disregards the system settings for the refresh rate of the internal monitor (M3 macbook pro), so that it always works at a max 120 hz, but without guarantee that it always goes to 120 hz). This being said, with my code I donāt find that a Win architecture works any better.
Anyhow; the short of it is: I would have liked to test if I can improve some parts of my tests by staying entirely within the native architecture, skipping the Rosetta translation.
Could you try brew install --cask psychopy or a developers install using a separate installation of Python? Personally I use Visual Studio Code to run PsychoPy 2024.3.0 (the dev branch) to access and test the latest features. However, I may have misunderstood what you mean by native build.
Donāt worry about spamming the list if you keep to this thread.
For the virtual frames issue, would it make sense to try updates / Each Frame code which only runs when frameN % 2 == 0 ? If this works then itās possible that PsychoPy could be modified to automatically detect virtual frames and adjust Builder behaviour accordingly.
@llb the point Iām making is that yes, indeed, the frame timing is broken and I believe this is at the level of the operating system because I believe the OS is doing strange things. That isnāt something weāre able to control right now. That also chimes with what Mario Kleiner says on the Psychtoolbox forum (he says donāt use macos at all for anything with frame-precise timing). This stuff used to work in older versions of the OS but now doesnāt
But none of this is to do with Rosetta. The frame timing is also broken on intel macs with recent macos and now Iāve tested on M1 mac with Arm architecture Python (no rosetta). All currently broken for frame-based timing
