More economical way to save Stimulator waveforms

Dear Jaewon,

we have a task that uses the same Stimulator object in two different scenes. Waveform numbers are set in between.
We now have the problem that the bhv2 files become way too large. A single trial uses around 3.5 MB, and with 400 trials we get more than 1 GB per session.
I found that the reason for this size is that the waveforms of the Stimulator object are saved in ObjectStatusRecord.SceneParam. Since the Stimulator is used twice, we get twice the size of the waveforms per trial.

I know, for bookkeeping this is good. But could you think about a more economical way of saving this information?

Best wishes,
Daniel

Download the new package and try it. I made the adapter accept a MAT file that contains waveform data.
https://monkeylogic.nimh.nih.gov/docs_RuntimeFunctions.html#Stimulator

Thanks, we'll try it.

It's not ideal, however, to deal with mat files. Wouldn't it be possible to save the unique waveforms once and have some kind of pointer to them? Seems like a major reorganisation of the bhv2 file format, though...

I have an idea. Could you allow function handles as input for Stimulator (and possibly ImageGraphic)? The pointed-to functions would only be called within the adapter and would return the waveform (and image matrices).
You could save the function handles' values (the pointer to the function name) in the bhv as a string.

Using a MAT file is exactly a way to save unique waveforms once and have a "pointer" to them. I don't think using a function handle is a good idea. There is no way to re-establish the link to the function unless you save it to a MAT file.

We organise our tasks in a Git repo. Since mat files are binary, they don't work well with Git.

Right now, if we want to parameterise stimuli like waveforms and save storage space, we would have to

[1] Create the waveforms in the beginning of the session, e.g. in the first call to the userloop function. Save the waveforms to a mat file.
[2] Pass the mat file name containing the waveforms to the adapter.

In the AdapterArgs there would only be the mat file's name. I could look up the parameters in the editables but I think it would be nicer to directly see it in the AdapterArgs.

The underlying function of a function handle can be extracted and thus would be easily traceable using Git.

I'll create my own subclasses that implement that and let you know how it works.

Actually, it works quite well. The function handle value is saved as a string in the bhv file.
See the attached files to reproduce.

I know a function handle is saved as a string, because I made it so. What I am saying is that there is no way to reconstruct the function handle from the string. There is str2func, but it doesn't check the validity of the handle and doesn't work for nested functions or if there is any externally scoped variable. As a result, the data file cannot be replayed.

I would just name the mat file with the function name and used parameters.

Jaewon Wrote:
-------------------------------------------------------
> I know a function handle is saved as a string,
> because I made it so. What I am saying is that
> there is no way to reconstruct the function handle
> from the string. There is str2func, but it doesn't
> check the validity of the handle and doesn't work
> for nested functions or if there is any externally
> scoped variable. As a result, the data file cannot
> be replayed.
>
> I would just name the mat file with the function
> name and used parameters.

Ah, I see. You're concerned about the replay functionality. We're never using that ...
However, if we were to rewrite our mat file every session, we could also not replay the session with the exact stimuli. Or we would have to save the mat along every session...

Anyways, since it works for our workflow, we are just going to use the custom adapters.