Moving dots and drifting gratings

Support
1

Hi Chris,

I’m trying to design a task for detecting changes in the speed of a stimulus. I’ve been playing around with both the drifting gratings and moving dots and have run into some issues with each.

For the drifting gratings, the problem is that when I change the speed of the stimulus, it resets the phase rather than smoothly transitioning to the new speed. I tried calculating and resetting the phase (based on the speed and spatial frequency of the stimulus, and how long it was drifting before the change) but this didn’t seem to solve the issue. Are there two phase parameters- one that is starting phase (and only works on initial painting of the stimulus) and another that controls instantaneous phase? However, I also tried repainting a new grating for the change condition (in which I told it the correct starting phase), but this didn’t work either. Any thoughts on what might be causing this issue?

For the moving dots, they do transition to a new speed without resetting their location. However, there are some problems with the parameters that control their properties. I have found that some of the parameters can only be controlled by hard-coding the default state in the XML. For whatever reason, using a temp variable in the stimulus descriptor does not work for these parameters: coherence, density and direction. Is this something that can be updated on your end?

Thanks,
Lindsey.

2

Hi Lindsey,

In both cases, you’re running in to limitations in the implementation of these stimuli.

In the case of moving dots, field radius, dot density, direction, coherence, and lifetime are all fixed at experiment load time. I think it would be straightforward to make the first three dynamically adjustable. I’m not so sure how dynamic changes to coherence and lifetime should be handled. Would the changes apply only to new dots (i.e. replacements for expired dots or dots that have drifted out of field), meaning there’d be a settling period for the changes? Or would all dots have their direction and/or age immediately reset based on the new parameters?

With the drifting grating, the phase at any given time is computed from starting phase, speed, spatial frequency, and elapsed time. Implicit in that is the assumption that those parameters are constant. I think this could be changed so that accumulated drift is recorded and used to compute the phase at each frame. That would eliminate the discontinuity when you change the speed.

I tried calculating and resetting the phase (based on the speed and spatial frequency of the stimulus, and how long it was drifting before the change) but this didn’t seem to solve the issue … I also tried repainting a new grating for the change condition (in which I told it the correct starting phase), but this didn’t work either.

I’m not sure why these didn’t work. Internally, the current phase is computed as follows:

starting_phase * (PI/180) + speed * spatial_frequency * (2*PI) * elapsed_seconds

Does that clarify things at all?

Chris

3

Hi Chris,

For coherence changes, I would want to have the parameter immediately reset
for the population of dots. This would allow me to start with a zero
coherence stimulus and then, by changing the coherence, instantaneously
transition to a stimulus with some directional movement. I haven’t really
thought about how to use dynamic changes in lifetimes.

That is the formula that I used to set the grating phase- but I used a
temporary variable to change the starting_phase parameter (and so it’s in
degrees, not radians). Is there a way to access the directly current
phase? It really feels like this should work- I must be doing something
silly- I’ll keep playing around with it…

Thanks,
Lindsey.

4

Hi Lindsey,

For coherence changes, I would want to have the parameter immediately reset
for the population of dots.

OK, that’s pretty easy. I’ll add it to my to-do list (and probably handle lifetime changes the same way).

Is there a way to access the directly current phase?

No, that’s not available from within an experiment.

Chris

5

Great- thanks!

6

Hi Lindsey,

As of the current nightly build, all moving dots parameters can be changed dynamically. As we discussed, changes to coherence and lifetime result in the direction and age, respectively, of all dots being reassigned. If you run into any issues or things don’t work as you’d expect, please let me know.

Cheers,
Chris

7

Thanks so much! I’ll test it out and let you know how it goes…
Lindsey.

8

Hi Lindsey,

Not sure if this is still relevant to you, but in case it is:

In the current nightly build, MWorks’ drifting grating stimulus has a new parameter: compute_phase_incrementally. If you set this parameter to YES, then changes to speed will be smooth and will no longer produce discontinuous phase jumps.

Although it may seem awkward or unnecessary to control this behavior via a parameter, I implemented it this way for two reasons:

  1. I didn’t want to change the default behavior (weird and unhelpful as it may seem).

  2. The old, non-incremental method for computing the phase has the advantage that, at any given time, the state of the grating is fully described by the values of its parameters at that time. In other words, a single #stimDisplayUpdate or #announceStimulus event contains all the information you need to reproduce the state of the grating at a given point in the experiment.

    In contrast, when the phase is computed incrementally, then you need the entire history of the grating’s parameters to reproduce its state at a given time. While all the required information should be in the event file, the reconstruction process is considerably more complicated.

If you have any questions or run in to any issues, please let me know.

Cheers,
Chris