Fixation point issue in 0.12

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