Hi Chris,
I’ve got a question about pulling out times that events happened in mworks.
I know I can pull out times that variables change in mworks, but there is a variable delay between when that happens and when the screen update happens. Usually our lab uses a flash in the upper corner and a photodiode to line up the screen update time/events in mworks/timing for neural data.
Unfortunately I neglected to get the photodiode data for many (~10) sessions of recording neural data, so now I am going through to reconstruct the timing post hoc. Rishi mentioned that I could use data from the variable #stimDisplayUpdate for this. I’ve seen this about how that works, so I’m trying to reconstruct using that.
Basically my plan is to find all the times that a certain stimulus appear on the screen (for example when two dots appear on the screen when the trial starts). In MATLAB, I’m simply only saving the times when the current #stimDisplayUpdate struct is equal to the #stimDisplayUpdate struct for when the two dots are on the screen.
My question is, do you think there is a better way to do this, a better variable to follow, etc?
Thanks!
Alex
Hi Alex,
Rishi mentioned that I could use data from the variable #stimDisplayUpdate for this.
Yes, in the absence of photodiode data, #stimDisplayUpdate times are your best estimate for when stimuli appeared on screen. (There’s a bit more info on this in the user manual.)
Be aware that there is some lag between when the display receives the rendered frame (which should happen right around the time indicated by #stimDisplayUpdate) and when the pixels actually change. On a responsive monitor, the physical update should begin within a few milliseconds. However, the update typically happens progressively throughout the refresh period, meaning pixels at the top of the display change within a few milliseconds, while those at the bottom of the display don’t change until near the end of the refresh period.
The timing of this delay varies by monitor, and you can’t really know what it is for a particular display without measuring. To do this, you can use a lag tester. (I think your lab may already have one of these, but if not, you’re welcome to borrow mine.)
In MATLAB, I’m simply only saving the times when the current #stimDisplayUpdate struct is equal to the #stimDisplayUpdate struct for when the two dots are on the screen.
I’m not sure I understand what you’re saying here. If you’re trying to extract the stimulus onset time, then you only need the first #stimDisplayUpdate event that includes the two dots, right?
Chris
Rishi mentioned that I could use data from the variable #stimDisplayUpdate for this.
Yes, in the absence of photodiode data, #stimDisplayUpdate times are your best estimate for when stimuli appeared on screen. (There’s a bit more info on this in the user manual.)
Be aware that there is some lag between when the display receives the rendered frame (which should happen right around the time indicated by #stimDisplayUpdate) and when the pixels actually change. On a responsive monitor, the physical update should begin within a few milliseconds. However, the update typically happens progressively throughout the refresh period, meaning pixels at the top of the display change within a few milliseconds, while those at the bottom of the display don’t change until near the end of the refresh period.
The timing of this delay varies by monitor, and you can’t really know what it is for a particular display without measuring. To do this, you can use a lag tester. (I think your lab may already have one of these, but if not, you’re welcome to borrow mine.)
Great thanks!
In MATLAB, I’m simply only saving the times when the current #stimDisplayUpdate struct is equal to the #stimDisplayUpdate struct for when the two dots are on the screen.
I’m not sure I understand what you’re saying here. If you’re trying to extract the stimulus onset time, then you only need the first #stimDisplayUpdate event that includes the two dots, right?
No, I need each time the two dots appear on the screen, that is the start of each trial. I think I figured it out by comparing structs in that way.
No, I need each time the two dots appear on the screen, that is the start of each trial. I think I figured it out by comparing structs in that way.
Oh, ok, I see what you mean now. In that case, what you really want is to check the name field of each struct to confirm that it’s the stimulus you want. For example, if the MATLAB variable sdu holds the value of a #stimDisplayUpdate event, and you’re looking for two stimuli called dot1 and dot2, then you’d perform a test like the following:
length(sdu.data) == 2 && strcmp(sdu.data{1}.name, 'dot1') && strcmp(sdu.data{2}.name, 'dot2')
If you compare the whole struct with the struct for a previous event (e.g. with isequal), you’re comparing all the parameters of the stimuli (position, color, etc.). Even if the dots are always displayed at the same location, there might be small differences in the recorded pos_x and pos_y values due to the details of floating-point representation. In that case, the structs would compare not equal, and you’d be excluding events that you actually want.
Chris
Okay, but I only want when a certain subset of these events are shown. Like these dots are on the screen most of the time, but other things change around them.
So probably I would have to compare the names of ALL of the things that are cued each time. (it seems to be 8 things displayed).
So probably I would have to compare the names of ALL of the things that are cued each time. (it seems to be 8 things displayed).
Well, you need to figure out how to uniquely identify the events that you’re interested in, based on what’s on screen at the time. Maybe you want #stimDisplayUpdate events that contain only the two dots, or maybe you want ones that contain the dots and other particular stimuli; it depends on how your experiment works. I was mostly just advising against comparing whole structs for equality, since that probably isn’t what you want.
You’re welcome to stop by my office to discuss further.
Chris