Chris,
As often before, we have a question related to our desire to keep our experiment files the same across all of our many expt rigs, and just use variables to make changes for each subject or rig.
We would like to encode the path for a video stimulus in a variable. Right now it looks like the VideoStimulus path parameter must be a string. We’ve tried using a variable, and using variable interpolation with ‘$’. No dice.
Our plan was to put the path in a variable, allow this to be edited before the experiment is run for the first time after load, and then the first time it’s run, call load_stimulus to load it. (VideoStimulus param ‘deferred’ set to ‘explicit’). Am I missing anything? If not, do you think you could alter the VideoStimulus to allow this?
Also, we don’t need to unload, change the path, and reload, but if that were possible and easy we’d probably use it.
Mark
Hi Mark,
Our plan was to put the path in a variable, allow this to be edited before the experiment is run for the first time after load, and then the first time it’s run, call load_stimulus to load it. (VideoStimulus param ‘deferred’ set to ‘explicit’). Am I missing anything?
There only piece you’re missing (and it’s easy to miss, since it’s not really documented anywhere) is that the video file(s) you want to use must be declared as file resources. The reason for this is that, in the absence of resource declarations, the experiment-loading apparatus infers the required resource files from components’ path attributes. This load-time inference assumes that the value of path is an explicit, relative or absolute path string, so attempts to use variables or expressions will fail.
Be aware: As noted in the docs, if your experiment declares any resources, then all other required files (e.g. images, sounds, Python scripts) must also be declared as resources. The simplest approach is probably to dump everything in a single directory (e.g. resources) and then use relative paths in to that directory (e.g. resources/videos/vid1.mp4).
Also, we don’t need to unload, change the path, and reload, but if that were possible and easy we’d probably use it.
That is all already possible.
Cheers,
Chris
Thanks for the info, Chris. Happy New Year!
I think I understand resource declarations now. (I also found these examples.)
What we want to do is to have a single MWEL file, whose text never changes, that allows loading different video files from different paths. It’s ok if we have to restart MWorks or reload experiments to change the video file. All of our rigs use a single version of the MWEL code for the experiment, and the thing that changes is the variables files. (The code and variables files are versioned through two different systems, one that is rig specific and one that is subject specific.)
Given what you said, it doesn’t sound like there is now a solution that will work for us. The closest would be to use a variable for a resource declaration, but that’s not allowed. Is there a solution I’m missing?
If I understand correctly, fundamentally the hurdle is that you want all the paths to resources specified at load time, and we want to put them in variables files that are by definition read after experiment load. Using the MWEL include facility doesn’t help solve this. What about adding an action like “update_resources” that resends resources to the server, and then this would allow resource paths to be variable/expressions/strings?
Mark
Hi Mark,
Given what you said, it doesn’t sound like there is now a solution that will work for us.
I guess I wasn’t being very clear, because I was trying to say that MWorks can already do exactly what you want. Please see this example. The “Select…” protocols just assign to the variable video_path and are stand-ins for loading a variable set.
If you can’t place all the videos you may want to use in a single directory, or you just want to avoid the expense of copying that whole directory when you load the experiment, then you’ll have to be a bit more clever, but your desired scheme is still 100% possible. The main thing is that you’ll have to get the video file (or a symbolic link to it) in to the experiment’s server-side working directory. I would probably do this with a simple Python script. If you want, I can provide another example demonstrating this approach.
Cheers,
Chris
Thanks for walking me through this.
Yes, we won’t be able to put all the possible videos in a single
directory. I have an idea of how to do your second suggestion, but it
would be helpful if you could give me a few example lines of Python that
created the symbolic link. The main missing piece for me is how to find
the server-side working directory. (In our setup we always run the server
and client on the same machine so this is no problem.)
Hi Mark,
Please see the attached example. In this version, you can set the variable video_path to any path you want, and the Python code will create a symlink to it when the you run the protocol.
The main missing piece for me is how to find the server-side working directory.
When MWorks executes Python code, it sets the current directory to the experiment’s working directory. You can see this in the example, which sets working_dir_video_path to a relative path (e.g. current_video.mov).
Cheers,
Chris
Attachment: runtime_video_path.zip (1.46 KB)