Hi Bram,
However, when I run the attached experiment in MWorks it says it cannot create the object; no Factory for dynamic_gabor_noise.
In DynamicGaborNoise::describeComponent, replace
info.setSignature("stimulus/DynamicGaborNoise");
with
info.setSignature("stimulus/dynamic_gabor_noise");
Alternatively, you could modify your experiment XML to request a stimulus of type “DynamicGaborNoise”, but the lowercase+underscores naming style is what all other MWorks components use, so I recommend that your plugin use it, too.
When is the “load" method called, after the queue stimulus command?
It depends on the value of the stimulus’s “deferred”" parameter. If “deferred” is omitted or set to “no”, then “load” is called when the stimulus instance is created, at experiment load time. If “deferred” is “yes”, then “load” is called the first time the stimulus is queued. Finally, if “deferred” is “explicit”, then “load” is never called implicitly, and the stimulus must be loaded explicitly via a “load_stimulus” action.
Is it possible to control the swapping of front and back buffers, e.g. draw 10 frames in the back buffer without swapping to the front buffer, after which normal front-back swapping takes place?
No, you can’t control buffer swapping. It might be possible for a plugin to render to an off-screen framebuffer and blit to the display buffer as needed, but I’d have to think about that some more.
Can you explain why you’d want to do this? Maybe there’s another solution that would meet your needs.
what does "play dynamic stimulus” internally do, in contrast to “update stimulus display”?
“update_stimulus_display” is required any time you want to change the set of stimuli being displayed. Stimulus queue/dequeue actions don’t take effect until you invoke “update_stimulus_display”.
“play_dynamic_stimulus” invokes the “play” method of a dynamic stimulus class. Subclasses of StandardDynamicStimulus won’t draw unless they’re playing, so in order to make them visible, you have to queue them and start them playing.
Since, in many cases, this is more confusing and annoying than useful, a while back I added an “autoplay” parameter to StandardDynamicStimulus (and thereby its subclasses). If “autoplay” is set to “YES”, then the first time the stimulus is asked to draw itself (typically when you invoke “update_stimulus_display” after queuing it), it will start playing automatically. Hence, by using “autoplay”, you can avoid invoking “play_dynamic_stimulus” altogether.
Cheers,
Chris