Some clicks/touches not registered?

Support
1

Hi Chris,

Now about the issue that I showed you on the ipad today. It also happens on the laptop, even on the latest mworks version, though somewhat less frequently on the laptop than the ipad. It’s not always the same number of clicks I have to do to get the error (anywhere between 2 and 30…)

It seems that the effector (I turned it visible, white square) faithfully follows the image around, and most times clicking/touching gives a reward, but on occasion it doesn’t register. I tried a change in minimal touch time and made the inter-trial interval a bit larger, not helping. And I now load and unload all images, this may have helped a little but did not solve it.

I made the output quite verbose (it tells you when it is waiting for the click/touch, and once it detected a touch “effector on match”, loading/unloading is reported automatically I think). It seems to just go into the state where it waits for a selection but does not register a touch, at random, and remains there for the full 2s and multiple click attempts.

Task can be run in the dropbox folder that I shared earlier (mworks4Chris),

…/Dropbox/mworks4Chris/MWorksTasks/subjects/Atomo.mwel can be run on the mac. Uncomment the include … ios_setup.mwel and comment the macos_setup if you want to switch to the ipad (in case you mac doesn’t show the error frequently enough, mine does though).

…/Dropbox/mworks4Chris/MWorksTasks/mwel/base_mwel/base_1stimNloc_protocol.mwel

Walks through the states and this is where I let it report what is on the console as well.

Perhaps it’s something trivial that I am doing, but the part where it happens really shouldn’t be different between trials, so I don’t see how a bug could be so random.

Thanks

Alina

2

Hi Alina,

I see what’s happening here.

Short version: In MWorksTasks/mwel/base_mwel/base_1stimNloc_protocol.mwel, in state “Start Stimulus Draws”, remove the following line:

effector_in_match_window = 0

Long version: A fixation point updates the variable assigned to trigger_flag only when the watched position transitions from being inside/outside the fixation window to outside/inside it. The issue you’re seeing happens when the change in position of the fixation point is small enough that, after the change, effector_x/effector_y still lie within the fixation window. Because the trigger state hasn’t changed, the trigger_flag variable isn’t re-assigned. This means that the value of zero you manually assigned to effector_in_match_window is never replaced, and your experiment never detects the touch/click.

I’m guessing that you set effector_in_match_window to zero to prevent premature selection (for example, if the subject holds their finger in the same position on screen between one trial and the next). If so, then I’d recommend that you instead make the start of each trial (or the start of the wait for selection) contingent on effector_on being false. That will ensure that there’s no active touch or mouse click before it’s time for the subject to make a selection.

Cheers,
Chris

3

Hi Chris,

This is indeed what is causing the bug but I cannot solve it by doing what you suggested, because it is then still possible to release, and touch ANYWHERE again and get a reward because the effector_in_match_window doesn’t reset. SO you only need one correct trial and after that you just need to touch anywhere.
I need to reset that variable somewhere I think… I will try to look at is asap, any suggestion highly appreciated because we have lab meeting now and after that I should hook up the animal or I will need to wait till tomorrow… not catastrophic of course but if you have a fast intuition how to solve that one, thanks!

4

This is indeed what is causing the bug but I cannot solve it by doing what you suggested, because it is then still possible to release, and touch ANYWHERE again and get a reward because the effector_in_match_window doesn’t reset. SO you only need one correct trial and after that you just need to touch anywhere.

I see what you’re saying, but I think that’s only true on a Mac. If you don’t move the cursor after a correct trial, you can indeed just keep clicking in the same spot to get rewarded – sorry for not seeing that earlier. However, on an iPad, the subject would have to release their finger and then touch the screen again in exactly the same spot to get an unearned reward. I don’t see that happening in practice.

To fix the problem on macOS, you could use the move_mouse_cursor action at the beginning of the trial to move the pointer to a position where you know the fixation point won’t be. That will both update effector_x/effector_y and cause effector_in_match_window to be set to false. Something like this (assuming (-15,-15) is out of the range where you’d be placing fixation points):

move_mouse_cursor (
    device = mouse_effector
    x_position = -15
    y_position = -15
    )

Chris