So I'm working on a task where I am loading in ~400 1 second clips (.avi). On my desktop which can run it, looking at the resource manager in Windows shows it basically loading all 50 GB of RAM I have. On my other machine, the stimulus presentation one, there is 16 GB of RAM, and the same tasks leads to a wait time of ~1 - 2 minutes, and then suddenly MATLAB closes without any prompt mentioning an error. It seems surprising that all of MATLAB should crash rather than MonkeyLogic giving some sort of error.

Can userloop be used in a non-preloading setting? I wrote this script a while ago and I was under the impression it was only for pre-loading stimuli. I'm guessing if instead of creating a large persistent variable, I call the 'mltaskobject' every loop right before the stim, it should avoid the crash but create a higher floor on the ITI. Is that correct?

You were under a wrong impression. Pre-loading should be exceptionally used only for large stimuli that are repeatedly presented. The userloop is supposed to return a char array or a cell char array, like {'fix(0,0)','pic(A,0,0)'}, and works just like a conditions file.
https://monkeylogic.nimh.nih.gov/docs_CreatingTask.html#Userloop

Ah ok, so I wrote the script this way and I'm running into a really odd problem.

Instead of generating TaskObj as a persistent variable, and generating it with the entire list of stimuli via mltaskobject, i choose the fixation dot and the condition, run each through mltaskobject seperately, and stick them together before passing them out of the userloop as C.

For some reason, in the 'persistent TaskObj' version, the task works as expected, but in the non-persistent TaskObj version, the fixation dot shows up, and it stays on the entire time, without the stimuli showing up (despite the time line on the side looking the same). Any clue what might be up? As far as I can tell, the structure C being passed out in both cases is identical.

Update: Some Visuals

This code produces the described problem

persistent TaskObjectFix
if isempty(TaskObjectFix)
  TaskObjectFix = mltaskobject(stimStruct(end), MLConfig, TrialRecord);
end

% Make the choosen items into TaskObjects
TaskObjCon =  mltaskobject(stimStruct(condition), MLConfig, TrialRecord);

C = [TaskObjectFix, TaskObjCon];
RunTime = get_function_handle(embed_timingfile(MLConfig,timingfile,userdefined_trialholder));

This code works fine

% persistent TaskObjectFix
% if isempty(TaskObjectFix)
%   TaskObjectFix = mltaskobject(stimStruct(end), MLConfig, TrialRecord);
% end

% Make the choosen items into TaskObjects
TaskObjBoth =  mltaskobject(stimStruct(1, [end, condition]), MLConfig, TrialRecord);

C = TaskObjBoth;
RunTime = get_function_handle(embed_timingfile(MLConfig,timingfile,userdefined_trialholder));

Both produce a C which looks the same, for all intents and purposes, a 1 * 2 mltaskobject, with the same fields in the same shapes.

The C produced by the first script is not the same as the one in the second script. They just look the same. To make the first script work, you should make TaskObjCon persistent or return a char array (a struct in your case) as I said above.

C = stimStruct([end condition]);

TaskObjCon needs to be regenerated everytime, because it is the task object corresponding to the current condition, why make it persistent? Also I don't understand why in one case you'd need to pass stimStruct through the mltaskobject and in another case not.

A variable being persistent does not mean that it has to be a constant. You can still update it as many times as you want. If TaskObjCon is not persistent, the taskobject created is destroyed, when the userloop returns, and becomes unavailable within the timing script.

Normally you do not pass stimStruct through the mltaskobject. It is only for preloading.