Fixation point issue in 0.12

Support
1

Hi Chris,

I have a bigger issue related to the behavior of fixation points in 0.12.

The same code that used to run in 0.11 now aborts even when the monkey fixates.

Could you please support backward compatibility in the next release? I would like to run the same experiments, but they won’t work with 0.12. For instance, the experiments in the shared dropbox folder won’t work in 0.12 even when the monkey fixates. In total, I need to replicate 10 experiments in a new monkey and hope I don’t have to change the MWorks protocol.

Thanks,

Yoon

2

Hi Yoon,

Can you please provide some more details? In what way does the code “abort”? Also, I assume you’re running the nightly build, not 0.12 or 0.12.1, since you couldn’t even load your experiment in those.

Have you modified the experiments in the shared Dropbox folder you referenced since running them successfully on 0.11? I ask because
1_RSVP_shapes/1_shapes.mwel, for example, looks to be controlling fixation point visibility via the alpha multiplier (one of the potential workarounds I suggested), but Dropbox claims it hasn’t been modified since 1/31/2023.

Thanks,
Chris

3

Hi Chris,

In the nightly build, a RSVP trial aborts after the first image flashes on & off. Even though the monkey fixated, the trial aborted before the second image comes up. I couldn’t run it on 0.12 or 0.12.1 due to the eyelink error.

And yes, I haven’t modified the experiments whatsoever.

Do you want to run the monkey again next week and collect logs when the trial aborts prematurely?

Best,

Yoon

4

Hi Yoon,

So it aborts as if fixation is broken, even though the monkey is fixating? Which experiment in the Dropbox folder is this (or is it literally all of them)? I should be able to test it for myself, possibly with the addition of a fake monkey. If not, then you can show me next week.

Thanks,
Chris

5

Yes, your description is correct – the monkey fixates but the trial aborts as if fixation is broken. Sarah, Ani, and I noticed this together.

I only tested with the experiment in 2_RSVP_NSD-COCO (from the Dropbox folder), but the eye tracking code is essentially the same across all experiments.

I’m happy to provide any information in case it helps assessing the situation.

Thanks,

Yoon

6

Hi Yoon,

Thanks for the additional info.

You’re right: The change to fixation point behavior is definitely the problem. Specifically, in state “RSVP stim on”, the experiment dequeues the fixation point at the same time as it queues the image stimulus. This causes eye_in_window to be set to false, so the experiment immediately transitions to “RSVP stim reject”.

Here’s the history of the fixation point change: Another lab was developing an experiment with multiple fixation points, where different fixation points triggered different outcomes, and not all of them were used in every scenario. The fact that all of the fixation points were always active complicated the protocol design, because flags for irrelevant scenarios could be set at any time. (Or something like that – I forget the exact details.)

When those folks brought the issue to my attention, my reaction was, “Duh! Of course fixation points that aren’t on screen shouldn’t be active, because how can you fixate on something you can’t see?” It seemed like an obvious oversight that should be fixed. (There’s even an ancient comment in the source code from Jim DiCarlo saying that fixation points should work this way.) Although it was clearly a backwards-incompatible change, the old behavior seemed so unreasonable that I didn’t think anyone would rely on it.

On the last point, it seems that I was wrong. I apologize for the frustration this has caused for you and others, and I want to make it easier for you to transition to the latest version of MWorks. That said, I think it would be a bad idea just to revert the change or to make the new behavior opt-in. This would cause experiments that were designed around the new behavior to start failing in non-obvious ways (e.g. with potential false-positive fixation tests). While there are undoubtedly more experiments designed around the old behavior, their failure mode should generally be much more obvious (i.e. false-negative fixation tests). (I suppose this assessment would be reversed in experiments where non-fixation on a hidden fixation point is the success condition, but I don’t know if that’s really a thing anyone does.)

Given this, my proposal is to add a new parameter, active_when_hidden, to fixation points. It would default to false, preserving the new behavior, but if set to true, it would restore the old behavior. You’ll still have to update your old experiments, but instead of changing the details of your experimental logic (and thereby potentially introducing errors in to said logic), you’ll just need to add a single parameter to your fixation point(s). I would make this change in the nightly build first. Once you’ve tested it there (and confirmed that there isn’t any other way in which I’ve broken your experiments), I’ll include it in MWorks 0.12.2 along with the fixes for the EyeLink issues.

How does this sound to you? I should say that I’m not 100% convinced that we shouldn’t revert fixation points to their old behavior by default and make the new behavior opt-in. Clearly, that’s what I should have done in the first place, but at this point it seems like a more problematic option than what I’ve proposed. However, I am open to arguments to the contrary.

Thanks,
Chris

7

Hi Chris,

Your solution would work for me. I’m happy to test out a nightly build as well.

I added Alina in this thread since the change will affect her experiments, too.

Let me know when to test the nightly build.

Thanks,

Yoon

8

This sounds like a much nicer solution than the repeated changes I needed to make to my code. My fp definition is it’s own mworks file anyway so that is literally a single change for me. Thanks!

9

Hi Yoon & Alina,

OK, sounds good. Thanks for your feedback and flexibility. I’ll let you know as soon as the change is in the nightly build.

Cheers,
Chris

10

Hi Yoon & Alina,

The fixation point fix is now in the MWorks nightly build. To restore the pre-0.12 behavior of fixation points, set the new parameter active_when_hidden to true, e.g.

circular_fixation_point fp (
    trigger_flag = eye_in_window
    active_when_hidden = true
    ...
    )

When you have a chance, please try this out and confirm that your existing experiments once again work as intended. Once I get your OK, I’ll roll this out as part of MWorks 0.12.2.

Thanks,
Chris

11

Hi Chris,

Sorry for the slow response. The nightly build works for me so far, but I haven’t tested it with a monkey yet – my monkey is recovering from a recent surgery. I hope to test it on a monkey observer next week. In any case, I haven’t found any issues so far and happy to release if Alina approves.

Thanks,

Yoon

12

Thanks, Yoon!

13

Well, I had this weird issue with the window not popping up. I don’t know if it’s the nightly build or if something messed with the mworks configuration somehow. I may try the nightly build again next week.

I had no issues with the fixation, but will say the python version changed and I had to update some python subfunctions as well.

14

the python version changed and I had to update some python subfunctions as well

Yes, the embedded Python version is now 3.11 in the nightly build (which eventually will become MWorks 0.13), but it will still be 3.10 in MWorks 0.12.2.

Thanks,
Chris

15

Hi Yoon & Alina,

MWorks 0.12.2 is now available and includes the new active_when_hidden parameter for fixation points. It also includes fixes for the EyeLink issues Yoon was having.

Cheers,
Chris