Experiments blocks while waiting for saccade to start

[nicolasJu]

Hi there,

I have being using pygaze in psychopy to run gaze contingent saccadic adaptation experiments. Until now I managed to get around a problem I already encountered before but I can't any more. Here is my problem : when I use tracker.wait_for_saccade_start(), this command pauses until this event occurs. However, I would like that my saccadic target rotates during the awaiting of the saccade using a visual stim that flips at each frame. So I guess what I would like to implement would look like:

while True: t = globalClock.getTime() stim.ori = t rotationRate 360.0 # set new rotation stim.draw() win.flip() if tracker.wait_for_saccade_start(): break

Or something like that. Bottom line, I need the my experiment not to pause until the saccade starts but still being able to detect it and react to it (change target position for example). I guess that would be on the while loop line 756. Or maybe if I just insert your code in my experimental loop including my rotating stim. What do you think?

I hope this is in the scope of the possible and I'm looking forward to your insights. Sincerely pygaze user, Judith

[arnohakk]

Hey, we have implemented such functionality using threading: We have the fixation detection running in a separate thread (same should be working with the saccade detection). It is important though that the screen presention is all handled by the main thread as Psychopy will otherwise make problems. Does this help?

[judithnicolas]

Thanks for answering. I've been trying to work something around with thread today, especially that i'm interested in getting ride of the sample rate limited by the vertical blanking. However, I'm still struggling since it's a new concept for me. So if you have a spare bit of code to show me a way that would very helpful and time saving!

[arnohakk]

I did not actually code this, perhaps @scattenlaeufer is so kind and can give a snippet?

[scattenlaeufer]

Our code isn't yet public, so I can't just show you how we implemented that way, but maybe I can try to explain it:

We create the eye tracker object within our main thread and create a fixation detector, which runs in its own thread. We then pass the eye tracker object to the fixation detector and let the later regularly check for fixations. If a fixation occurs, it is stored in a list within the fixation detector.

In the meantime the main thread is able to perform all the screen tasks we want and regularly checks the fixation list from the fixation detector. It then can perform all the test we want on this list to check for the kind of fixation, we are waiting for.

I hope this helped a bit. If not either ask or if I find the time next week, I'll write a short example of threading and detecting fixations.

At the and a small disclaimer: We are working with a Tobii eye tracker. I have no idea, to wich extend other eye tracker are able to be accessed from another thread than the main thread. At the moment we still have some unresolved issues with using the dummy tracker and our multithreading code, so there is at least a small possibility that our way of threading might cause problems with your hardware.

On 02/19 02:47, arnohakk wrote:

I did not actually code this, perhaps @scattenlaeufer is so kind and can give a snippet?

-- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: https://github.com/esdalmaijer/PyGaze/issues/110#issuecomment-366820617

[nicolasJu]

Thank you very much for your explanation. In the meantime, I actually manage to code that by myself (I just finished all the sanity checks today !).

I'm planning to published the bit of example but I need to clean my script first.

The only thing I was disappointed about is that any way, graphic cards seem to have a buffer frame that does not allow to have a latency within a frame duration although you're samplig at 1000 Hz...