Frame list enhancement bugs?

Support
1

Hi Chris,

I’m using the “ending” flag for the first time, and I’m either not using it correctly or there are bugs. Here’s the definition:

<stimulus type="frame_list" tag="ballInterval1" stimulus_group="ball1Frames" ended="" ending="stimEnding" repeats="round(setDur*refreshRate())" loop="NO" autoplay="YES"></stimulus>

And here’s the transition:

<transition type="conditional" tag="If stimEnding, Transition to GoState" condition="stimEnding" target="GoState"></transition>

It always works the first time. On my first try, the second trial resulted in a stimulus of 0 length, as “stimEnding” doesn’t automatically get reset to 0. After adding an explicit reset assignment at the beginning of the state, the second trial resulted in the stimulus not playing at all.

Evan

2

Hi Evan,

After adding an explicit reset assignment at the beginning of the state, the second trial resulted in the stimulus not playing at all.

Do you dequeue the stimulus at the end of each trial? Dynamic stimuli don’t “rewind” automatically. In order to reset a completed frame list so that it plays again, you need to either dequeue and re-queue it, or invoke “stop_dynamic_stimulus” followed by “play_dynamic_stimulus” on it.

Chris

3

Hi Chris,

Yes, I’ve done that. I’m modifying an existing working program,
queueing/dequeuing is already in place.

  • Evan
4

Hi Evan,

OK, I see the problem now. If you want to play a frame list more than once and receive ending/ended notifications each time, you must invoke “stop_dynamic_stimulus” between repetitions. (If “autoplay” is “YES”, no corresponding “play_dynamic_stimulus” is necessary.) Sorry for the confusion.

While it seems like “autoplay” should also imply “autostop”, I’m not sure that’s possible with MWorks’ current visual stimulus architecture. Let me think about it and see if there are any good options.

Thanks,
Chris

5

Hi Chris,

Great, it works now. I’m a little surprised that this wasn’t a problem before when I had loop="YES".

Thanks,
Evan

6

Actually, now that I think about it, I guess it could have just been that the stimulus was never “stopped” before, just dequeued. Is that the case?

7

I’m a little surprised that this wasn’t a problem before when I had loop=“YES” … Actually, now that I think about it, I guess it could have just been that the stimulus was never “stopped” before, just dequeued. Is that the case?

Right. When set to loop, the frame list never reaches the end (and, hence, never issues “ending” or “ended” notifications). You could dequeue and re-queue it repeatedly, and, so long as you never explicitly stop it, it would keep playing indefinitely.

Chris

8

Hi Evan,

While it seems like “autoplay” should also imply “autostop”, I’m not sure that’s possible with MWorks’ current visual stimulus architecture.

It turns out that it is possible. Starting with tonight’s nightly build, an autoplaying stimulus will now automatically stop when dequeued.

Cheers,
Chris

9

Sounds great. I’ll remove the stop actions from my programs and let you know if I run into any issues.

Evan

10

Hi Chris,

Is this in the nightly yet? I just tried removing my stop_dynamic_stimulus actions and they behaved as though they hadn’t been stopped.

Evan

11

Yes, it’s in the nightly. Are you running a update_stimulus_display action between dequeuing and re-queueing the stimulus?

Chris

12

Hi Evan,

Thanks for the example. The problem is just what I suggested: You need an update_stimulus_display between dequeue_stimulus and queue_stimulus.

The reason you need it is that queue/dequeue actions aren’t executed immediately. Instead, they set a “pending” flag on the stimulus. That flag is read inside update_stimulus_display, which performs the actual queue/dequeue action.

I’ll email you an updated version of your experiment that works correctly without explicit stops.

Chris

13

Thanks Chris, I had forgotten that I waited to dequeue the last presentation until just before the current presentation.