Following up on upgrading the rig with the new Mac Studio.
Upshot: MWorks version 0.11 works, but does not with versions 0.12 and 0.12.1
The good news is that I haven’t found any issues with MWorks version 0.11. I am not seeing issues related to video glitches. I will continue to verify the system by training a monkey in the rig.
However, in terms of forward compatibility, I haven’t found a solution for MWorks version 0.12+. I attached macOS’s error log but couldn’t make much sense out of it yet. Here are some technical details for replicating the issue with versions 0.12 and up:
Error: crashes with when “playing” the experiment. Basic example experiments work well. However, if the experiment contains ‘iodevices/eyelink’, the application freezes and crashes with the OS logs (attached).
Eye tracker: Eyelink 1000Plus; verified connectivity with SR Research’s tracking application
MWorks Server is run with Rosetta 2
MWorks Client is not run with Rosetta 2 (Rosetta didn’t matter for the client, turns out)
No, I am running MWorks 0.11 on macOS 13.5. I used the latest driver for Eyelink 1000Plus. I noticed SR Research apps (e.g., Tracker) ran natively and did not have an option for running on Rosetta.
Lastly, I wondered if app permission could be an issue and made sure I granted permission for ‘input monitoring’, i.e., System settings > Privacy & Security > Input Monitoring > enable ‘MWServer’. I think this only applies for peripherals, but just wanted to let you know.
If all fails, I can set up TeamViewer or VNC for you to access the machine remotely.
A change made in MWorks 0.12 caused creation of the EyeLink data file to fail. While that should just produce a warning from MWorks, an undocumented change to the EyeLink API causes the failure to lead to a MWServer crash. I don’t know when the latter change happened, but it’s present in the previous release of the EyeLink drivers.
The reason I saw a crash in MWorks 0.11 while you didn’t is that I was triggering a different EyeLink error – specifically, I was attempting to connect to a non-existent tracker. I think this means that, even with 0.11, any EyeLink error is going to crash MWServer. Hopefully you won’t hit any such errors, but just be aware.
For the moment, sticking with MWorks 0.11 is the right move. I will get fixes for both issues into the nightly build soon. This probably also warrants a 0.12.2 release.
I tested the nightly build (version dev 0.13) on the Mac Studio (Ventura 13.5.1). Here is what I see so far:
The eyelink issue is no longer present. I can run experiments.
However, I noticed a new behavior. In general, I manually change the ‘eye_in_window’ variable to ‘true’ to keep the experiment running without an actual observer. In the nightly build, the parameter value resets each trial. So, I now have to change the parameter value in each trial whereas this was not the case before.
The eyelink issue is no longer present. I can run experiments.
Great! The folks at NIH report success with the nightly build, too, so I will push these fixes out in MWorks 0.12.2 soon.
In general, I manually change the ‘eye_in_window’ variable to ‘true’ to keep the experiment running without an actual observer. In the nightly build, the parameter value resets each trial. So, I now have to change the parameter value in each trial whereas this was not the case before.
The behavior of fixation points changed slightly in MWorks 0.12. See this comment for details. One possible workaround is to do as I suggested in that comment: Keep the fixation point on screen at all times, and make it transparent when you want to hide it. Another option would be to add a new variable (e.g. simulate_fixation). After queueing the fixation point, if the value of the variable is true, your experiment can set eye_in_window to true.
MWorks 0.12.2 is now available and includes the fixes for the EyeLink issues you were having. Also, as of 0.12.2, MWorks’ EyeLink interface supports both Apple silicon and Intel processors. Apple silicon support requires the latest version of the EyeLink Developers Kit.