expStart event can update before t signal

[k1o0]

exp.SignalsExp after wiring the network adds an event handler whose callback updates events.expStart and therefore any other dependent events such as events.newTrial, events.trialNum, events.repeatNum and the conditional parameters:

Rigbox/+exp/SignalsExp.m

Lines 350 to 353 in 4ff1a21

	%set pending handler to begin the experiment 'PreDelay' secs from now
	start = exp.EventHandler('experimentInit', exp.StartPhase('experiment'));
	start.addCallback(@(varargin) obj.Events.expStart.post(ref));
	obj.Pending = dueHandlerInfo(obj, start, initInfo, obj.Clock.now + obj.PreDelay);

Immediately after doing so it enters the main experiment loop, where the t and input signals get values. On fast computers, when the PreDelay is 0, callback is executed before entering the main loop, and therefore events.expStart, etc. updates before the inputs. On slow computers or when the PreDelay is sufficiently long, these events update after the input signals have taken their first values.

The problem here is that particular derived Signals will behave inconsistently depending on which signal updates first. In the below example, the signal trigger may never update on the first trial is t is sampled by event.newTrial before it has any value.

trigger = t - t.at(events.newTrial) > p.timeInterval;

It is reasonable to assume that the t and signal in particular should be the first to update. This problem may well be the cause of issue #45. A solution here could be to have the callback update t before anything else.

[k1o0]

The following solution fixes the behaviour as expected:

start.addCallback(...
  @(~,t)iff(obj.Time.Node.CurrValue, [], @()obj.Time.post(t)));

There is a minute chance of t updating just as this callback occurs, in which case it might do backwards by a few milliseconds but this is very, very unlikely. The greater problem is that this doesn't solve similar issues with input signals, which is one cause of hard crashes (i.e. when a stimulus parameter depends on an as yet undefined signal).

I think the root issues need to be solved first anyway (stimuli causing MATLAB crashes) and it's perhaps more reasonable to assume the inputs might take a value after expStart than the t signal.