Validated now. It can take anywhere between hours and weeks from arrival of payment to when I can see it in my database, as there is a busy human in the loop other than me. Hence the advice to buy the membership well in advance.
So the reason this does not work, is that dontsync option 1 will indeed prevent your script from waiting until a flip completes, synchronized to the start of video refresh/vblank, at the cost of no longer getting a visual onset timestamp anymore. But there is only a limited amount of OpenGL image buffers your script can render to ahead of displaying them, typically 1 - 3 at most depending, on operating system, graphics card and system config. Once those are all filled and 'Flip’ped with new stimulus images, ‘Flip’ is forced by the operating system to block again, until at least one of the image buffers is consumed and shown by the display and freed up for reuse → you are back to lock-step with the video refresh at 60 Hz, or 60 presentation loop iterations per second. Essentially this can be useful if one only expects small “jitter” in drawing, but not to compensate for a situation where one wants to execute ones drawing loop at an average rate higher than the video refresh rate, like in your case where you want to sample the joystick faster than 60 samples per second. Using dontsync 2 would disable vsync and this throttling on many setups, but then your stimulus would be visually corrupted/undefined by tearing. PsychDebugConfiguration will cause routing of images through the desktop compositor for visual transparency, and disassociate the presentation cycle of your script from that of the compositor/display, again at the cost of no timing precision and the compositor likely dropping various stimulus frames at its discretion → Undefined stimulus presentation and timing again, where some of your stimuli may never show onscreen, and photo-diodes might get confused and fool you as well. So many ways to fool oneself with photo-diodes if one doesn’t understand the display system very well.
What you want to do is depending on operating system or the need for compatibility across operating systems. But seeing you chose Linux, that allows for the most elegant solution:
If you can restrict your script to Linux, and use our joystick / Gamepad support, you could simply record the joysticks motion in the background, independent of the execution and redraw rate of your Matlab display script. Our Keyboard queues on Linux can also record time-stamped mouse movement trajectories, and joysticks under Linux are just treated as unusual mice, so this works with joysticks as well.
Look at MouseMotionRecordingDemo.m and replace GetMouseIndices with GetGamepadIndices. [a,b] = GetGamepadIndices will list device name strings in variable ‘b’. Choose the one matching your joystick, say e.g., it is called ‘NameOfMyJoystick’, and then you can call
d = GetGamepadIndices('NameOfMyJoystick') in the modified MouseMotionRecordingDemo.m to get it to record joystick motioon and get an idea how this works. With timestamped events for each joystick movement.
The same technique would work for mice on MS-Windows, but not for joysticks atm… It would not work at all on macOS.
In your code you could use KbQueueStart/Stop to start/stop joystick movement data collection for a trial, KbEventFlush to discard data from a previous trial at the start of a new trial, and the kind of while loop shown in that demo inside the animation loop of your script, to fetch and store away whatever data is available during a single iteration of your drawing loop, and then use the last fetched item to update visible position of your stimulus cursor, redraw and then ‘Flip’ the updated stimulus image again conventionally, rinse, wash, repeat.
Let us know how that goes, or if you need a more detailed explanation. Or a less elegant / powerful solution that should work cross-platform though, by polling use of AsyncFlips.
-mario
[14 out of 30 minutes paid time used].