Previously, certain gain values were hard coded with the assumption that one would always want a standard closed-loop experiment on each block up until a halt is applied. Normally this means always setting the global delta gains to 1 at the start of closed loop and then setting to e.g. 0 for the halt period.
Issue #75 relates to wanting to do this in reverse, with no closed-loop feedback at the start of each trial and closed-loop feedback initiated during the halt period.
This PR updates the schema and workflow to allow the user to set parameters regarding the behaviour of closed-loop feedback at the start of a trial and during the halt period, separate from the gains that control e.g. flow to visual gain. In short, this gives the user to do a 'reverse-halt' experiment where closed-loop is off initially and then turned on during a halt period.
Also noticed while working on this that halt gains were being set in the wrong places, with parameterised application happening AFTER the halt duration timer. We got away with this so far because there was a hard-coded set to 0 at the start of the halt application and generally users pick 0 as the haltGain parameter so this bug was not actually encountered until now.
Relates to issue #75
Previously, certain gain values were hard coded with the assumption that one would always want a standard closed-loop experiment on each block up until a halt is applied. Normally this means always setting the global delta gains to 1 at the start of closed loop and then setting to e.g. 0 for the halt period.
Issue #75 relates to wanting to do this in reverse, with no closed-loop feedback at the start of each trial and closed-loop feedback initiated during the halt period.
This PR updates the schema and workflow to allow the user to set parameters regarding the behaviour of closed-loop feedback at the start of a trial and during the halt period, separate from the gains that control e.g. flow to visual gain. In short, this gives the user to do a 'reverse-halt' experiment where closed-loop is off initially and then turned on during a halt period.
Also noticed while working on this that halt gains were being set in the wrong places, with parameterised application happening AFTER the halt duration timer. We got away with this so far because there was a hard-coded set to 0 at the start of the halt application and generally users pick 0 as the haltGain parameter so this bug was not actually encountered until now.