Help with workflow conditional logic?

[preinagel]

TLDR: how do you cascade multiple takeUntils?

The overall context is using Bonsai (w/Bonvision) to display visual stimuli, under the control of another device (Bpod), interacting via soft codes. I'm trying to modify a working Bonsai script and I'm befuddled about how to configure the conditional nodes to do what I want (due to persistent confusion about reactive programming logic).

What I want to do is insert a distinct ITI screen after the animal responds to the stimulus, and before returning to the ready state for a new trial. I would like the duration of the ITI to be controlled by Bpod, so the plan is to send a softcode to signal the transition from stimulus to ITI, and another one to transition from ITI to starting state.

I am attaching the functioning workflow. What I have come up with so far for the new functionality can be found (as a disabled, unconnected workflow) within the StimGoesLive workflow group. The question is how to sequence the conditionals (TakeUntil, SubscribeWhen, etc) to achieve the intended results.

WorkflowToFix.bonsai.zip

Thanks in advance, if anyone can help.

More context if needed: As of now there's an inner workflow group (StimGoesLive) which subscribes to a visual stimulus (DisplayStimulus) when an onset softcode is received, until an offset softcode is received. The outer workflow (DoTrial) then waits for an async subject (Params) to broadcast a new value specifying the next stimulus, as the trigger to subscribe to StimGoesLive again. The Params subject gets broadcast when a softcode specifying stimulus identity has been received and successfully interpreted. It's critical that these things happen in the correct order, so the workflow largely forces sequential operation instead of asynchronous behavior.

A constraint is that all softcode values have been used, so I'll need to re-use a softcode. My thinking is that once the onset code has been received, the workflow could wait for a second onset code to indicate transition to ITI, and then use the offset code to transition to the starting state (as it is used now).

[aspaNeuro]

The logic for creating this type of control logic is well described in the State Machines Tutorial

There are many ways to solve this problem I'm going describe the way I would do it:

1. SerialRead is an IO input, I would suggest that you use it only once in the workflow and publish it to a publish subject (in the main workflow), anywhere you need to know or wait for something coming from serial (bpod) subscribe to that subject.
2. The (StimGoesLive) could be promoted to a 'SelectMany' in the main workflow that starts with the output from (StimParamsSet) also promoted to the main Workflow.
3. After that I would create another SelectMany with the control logic you need for the (timeoutblackscreen).
4. Then repeat.