Playing a set of movies in random order

Support
1

Hey Najib & Ha,

I’ve been working on your movie-playing question, and I have at least a partial solution.

The attached experiment demonstrates how to play a set of movies (of varying length) in random order. The movies are all defined within a stimulus group called “movies”. The range replicator “Trial Replicator” iterates over the stimulus group and generates one trial per movie. The block “New Block” runs through all the trials in random order.

Within each trial, the relevant movie is loaded, queued, played, dequeued, and unloaded. The loading/unloading depends on a change I implemented last Friday, which lets you load/unload all the frames of a movie by loading/unloading the movie stimulus (i.e. it saves you the trouble of having to loop over the frames yourself). Thus, you’ll need a very recent nightly build in order to run the example.

The only issue that I haven’t resolved to my satisfaction is how to specify the frames for each movie. In my example, the stimulus groups containing the frames are hard-coded, i.e. there’s a separate definition for every group and every frame within each group. Obviously, specifying things this way gets unwieldy when you’re dealing with thousands of frames. I thought I would be able to use some combination of range and list replicators to define the frames concisely. However, there’s a bug in the XML parser that prevents this from working, and I don’t see any easy fix for it.

At this point, I think your best bet is to use a Python script to generate the XML that defines the movie frames, and then copy that into your experiment XML. Although it’s a far from ideal solution, it is something that will work right now, and it also will let you organize and name your image files however you want.

Thinking a little longer term (i.e. not for this week), do you guys have any suggestions for how you would like to specify your movie frames? Apart from making the range/list replicator approach work, I can imagine various other ways of doing it. For example, the movie stimulus could take a directory name and find all the image files in it, or you could specify the frame list in a text file. Any thoughts on what would be most appealing?

Chris

2

Attachment: movies_random_order.xml (5.96 KB)

3

Hey guys,

The experiment preprocessor feature that I told you about last week is now in the nightly build. As I’ll describe below, it opens up alternative ways of defining your movies.

To specify a preprocessor for your experiment, you include a string of the form mwpp="/path/to/preprocessor" somewhere in the first two lines of your experiment file. (Note that “mwpp” must be preceded by at least one whitespace character.) As you probably guessed, /path/to/preprocessor gives the absolute path to the preprocessor program.

The preprocessor program must be an executable file. (If it’s a Python or shell script, it must begin with an appropriate #! line.) It must accept a single command-line argument, which gives the path to the experiment file to process. It can process the input file in any way it likes, but the end result must be a valid MWorks experiment XML file, written to standard output.

I’ve attached an example that demonstrates how to use the preprocessor. The experiment it defines is equivalent to my previous, plain-old-MWorks-XML example. However, instead of using range replicators or defining every stimulus individually, it uses a preprocessor to generate the repetitive pieces of the experiment dynamically. In this case, the preprocessor is the script mako-render, which is part of the Mako template library. You can learn about the template directives in Mako’s syntax documentation, but if you’ve used Python-based template engines before, it will probably seem familiar.

To be clear, I used Mako because I like it. However, the preprocessor program can be anything you like, so long as it conforms to the interface described above. You’re free to use Cheetah or another template engine, or you can write a completely custom preprocessor. As long as the end result is valid MWorks experiment XML, there are no restrictions.

Clearly, the preprocessor is intended for advanced, “power user”-type folks. I’m also working on the simpler, more user-friendly tool for your problem, i.e. directory-based movie stimuli. I’ll let you now as soon as that’s available for testing.

Chris

4

Attachment: movies_random_order.mako (4.67 KB)

5

Hey guys,

The new, directory-based movie stimulus is now in the nightly build and ready for you to test. In the editor, it’s called “Image Directory Movie Stimulus”. Here’s how it’s defined in XML:

<stimulus type="image_directory_movie"
          tag="New Image Directory Movie"
          directory_path=""
          x_size="5.0"
          y_size="5.0"
          x_position="0.0"
          y_position="0.0"
          rotation="0.0"
          alpha_multiplier="1.0"
          deferred="no"
          frames_per_second="10"
          ended=""
          loop="0" />

As you can see from its parameters, it’s basically a fusion of the existing movie and image file stimuli. The only new parameter is “directory_path”, which specifies the path (either absolute or relative to your experiment file) to the directory that contains the images you want to use as frames. The frames are ordered according to the ASCII sort order of the image file names, which should be the same as the default order given by ls.

At present, the stimulus expects the directory to contain only image files. If any of the files can’t be opened as images, the experiment will fail to load. If this proves too restrictive (e.g. you find that you want to include a README or some other non-image files in the directory), then I can try to make the plugin smarter, maybe by using the extension to guess which files are images. Let me know.

Compared with the existing movie stimulus, the new one eliminates the need to define stimulus groups full of image stimuli. However, to play a bunch of movies in random order, you’ll still need to create a stimulus group of movies. To do that, you’ll need to either use a range replicator or define each movie explicitly. (Alternatively, you could use a preprocessor to do something fancy.)

Please give this a try and let me know how it works for you.

Thanks,
Chris

6

hi chris,

finally got to thoroughly test this plug-in.
it is 99% there, there is one glitch that has taken me the past two hours to figure out.

making the assumption that directories only contain image files is a bad assumption on a make :slight_smile:
that isn’t due to any README files, that is due to the darn .DS_STORE files that MacOSX generates and you simply can’t delete them.

i presume it is a simple fix, now i understand why FILENAMES(*) might cause a headache for you guys :wink:

best
najib

7

Hi Najib,

making the assumption that directories only contain image files is a bad assumption on a make :slight_smile: that isn’t due to any README files, that is due to the darn .DS_STORE files that MacOSX generates and you simply can’t delete them.

I changed the file-discovery code to ignore hidden files (i.e. any file whose name starts with “.”).

Also, I changed the filenames() directive so that it matches any file type (not just regular files). This will allow you to replicate over directories of directories.

Both of these changes will be in tonight’s nightly build.

Chris