I’m running an experiment with both audio and visual components. I’d like to get the onset of both audio and visual stimuli. I’m using Psychtoolbox as the audio backend which has a different clock than what the Window object uses as default. Is it possible that when I call win.flip() the time according to the Psychtoolbox clock will be returned? I saw that if I use continuous window flips then I can use win.getFutureFlipTime(clock='ptb') but it would be nice if at any point a time is returned from an object or event it would be in the Psychtoolbox clock. Please let me know if this is possible. Thank you in advance.
Are you coding an experiment from scratch or using Builder - if you are using builder the onset times of those stimuli will be saved to output by default (and you can use ptb backend for sound)
Sorry for the late reply. I’m building from scratch. There are a few different clocks that I would like to have on the same time: Window flips, Sound onsets, Eyetracker (tobii) time. I’m using psychtoolbox for audio and so I’ve been also using psychtoolbox for window flips. Is it possible to make eyetracker times in psychtoolbox time? Ideally everything would correspond to a single clock or an event would record the time from multiple clocks to synchronize everything. Thanks in advance.
Is there a particular reason to approach this from the coder side? Alot of this will be saved by default from builder and it usually is much faster to create the study!
The coder just gives me more control which I like. There’s also aspects of many experiments where the builder is insufficient or harder to implement something.
Fair enough! It looks like psychopy.clock will use the ptb clock when using getTime anyway if you use psychtoolbox.
ironically, what I would suggest is make a simple exp in builder, set audio library to ptb and input monitoring to psychtoolbox. Compile the experiment to python and look under the hood what code builder uses for the timestamps (Builder is created to control timing in the optimal way, it takes into account many things that can easily be missed in pure code experiments).
Hope this helps,
Becca
PS. I won’t try to oversell it, but as a convert from pure code myself - Builder may have more flexibility than you think (you can always add code in code snippets, Eyetrackers are super easy to integrate quickly, and lot’s of things are saved without having to think about how to reengineer it! - I would highly recommend giving it a go)
For the builder, I’ll give it another look. I do like it as a way to get code snippets and suggestions. But there are some things that I really like having more control over such as when a TTL is sent (I usually use win.callOnFlip()). Or when an experiment has multiple different types of paradigms but uses the same base code in which case I don’t have to duplicate a script but can just add options to a dialog. I also really like knowing precisely how everything works under the hood. It makes debugging loads easier.