workflow review (state-dependent visual studies and the use of AsyncSubject)

[chiyu1203]

Dear Bonsai community,
I have built up a workflow to present visual stimuli to animals when they are in certain state.
The workflow is working as fine as I can tell but Claude has some concerns over the use of BehaviorSubject inside SelectMany (to deliver visual stimuli). Therefore, I was hoping to ask for a second opinion here.
Also, the logics and nodes of the workflow are based on many discussion here and on the archived google group. I did not find a workflow that serves exactly the same function so I thought it would be good to publish it in case people find it useful.

Keywords: state-dependent stimulation (Schmitt trigger), refactory period, BonVision, fictrac,

The experiment is about presenting visual stimuli to head-fixed locusts only when they started to walk for longer than 1 second. Then the minimal interval between stimuli are 35 seconds (from the onset of previous stimulus to the onset of the next stimulus )
The animal's behaviour is estimated based on a third-party software, fictrac, which outputs the animal's heading direction, and x, y positions.
These outputs go into the workflow. Then rolling average of velocity is calculated with nodes taken from #2086
To create the condition of "walk for longer than 1 second", inside the node of WalkStatesStimuli, I first set two thresholds for the velocity under different state transition (Schmitt trigger, for more details), and then only pass stimulation trigger when the walk state lasts more than 1 second with nodes taken from #1278
Actually, once I implement Schmitt trigger and 1-second span, I can probably just use instaneous speed instead of rolling average
Additionally, to prevent delivering multiple stimuli at once, I set the refactory period to block stimulation trigger within 35 seconds (see here for more details). Lastly, SelectMany receives the stimulation trigger and the stimulus is present (50% of the trials is stimulus and the other 50% is transparent control, or skipped trial).

Here is the question. When I send the workflow to Claude and ask it to proof-reading the workflow based on the workflow guidelines. It raised a concern over the implementation inside SelectMany (PlayStimulus)

3. 🟡 PropertyMapping Inside Reentrant SelectMany (PlayStimulus)
   Guideline: "Avoid using PropertyMapping nodes inside reentrant nested operators."
   Problem: Inside WalkStatesStimuli → PlayStimulus (an rx:SelectMany), there are multiple PropertyMapping nodes pushing values into DrawTexturedModel and DrawQuad. Since SelectMany is reentrant (can run multiple overlapping instances), these property mappings can cause race conditions — the property on the target operator may be set by one instance just as another is reading it at subscribe time.
   Fix: Replace PropertyMapping nodes inside PlayStimulus with rx:AsyncSubject to pass the input value safely within the nested scope, then use WithLatestFrom to combine with the target operator's output.

PropertyMapping inside reentrant SelectMany — Inside PlayStimulus (rx:SelectMany), there are multiple PropertyMapping nodes used to push values into DrawTexturedModel and DrawQuad. This creates race conditions as warned by the guidelines.

MulticastSubject on non-BehaviorSubject — th_Stimulus and transparent_texture are declared as BehaviorSubject but updated via MulticastSubject, which is correct. However QuadState is a BehaviorSubject but is written from within the reentrant SelectMany via MulticastSubject — the race-condition-prone PropertyMapping issue applies here too.

Particulary, the concerns seem to be about me specifying QuadState (sync pulse state) with MulticastSubject, BehaviorSubject and receiving parameters with PropertyMapping. Based on the API documentation, I could get some idea what AsyncSubject is about. However, I still do not understand why using AsyncSubject inside the SelectMany. Could anyone give some suggestion?
Below is the screenshot inside SelectMany and inside WalkStatesStimuli and the workflow

state_dependant_visual_stimuli.bonsai.zip

Hope you enjoy reading my journey.
Please feel free to let me know if you have any comments on any part of the workflow. No matter it is not implemented efficently or causes some kind of race condition like that.

[Nickalus12]

[chiyu1203]

@Nickalus12 thanks for the comment. This is very helpful. It reminded me of race conditions in all of my workflows, which I was trying to circuvment by using 35s refractory period and/or adding SkipUntil right before DrawTexturedModel. I have replaced one BehaviorSubject with AsyncSbuject, but at all because the "kind of" tradition of the design in this workflow uses BehaviorSubject and MulticastSubject to update the indication of sub-states (stimulus appears/stimulus moves/stimulus stops/stimulus disappears) in a trial. However, these sub-states could have been implemented with their own SelectMany, so I guess this is why you pointed out that this workflow need a change in data flows??

In addition, I have managed to replace SelectMany with Defer. Since Defer can not accept input connection, if I want to combine your suggestion about

avoids the need for property mapping entirely by routing the "trigger" to two different SelectMany paths

(because I actually think it is a good idea to set the parameters in advance before they reach the nested workflow)
the best way is in fact to create two CreateObserverable with their own Defer and AsyncSubject. And then they can be activated depending on the condition of stimulus parameter?! Does that overcomplicate things?

I am not sure about how to implement this.

use CombineLatest inside the nested workflow to pair your trigger with the mapped properties

Although there are many examples of using CombineLatest, I could not find one example related to this application, and was not able to build a workflow based on the code you noted down. Could you point out or attach a workflow for me to check out?

Many thanks in advance.

[banchan86]

@chiyu1203 @Nickalus12 I'm sorry, but there seems to be too much AI going around in this discussion 😆. Personally, I am a fan of AI and Claude, but I am not sure that it "understands" Bonsai well enough. I think, used conservatively, it can be very powerful. I am not sure if the issues are real or hallucinations (and it's going to take some time to untangle).

We don't have an AI use policy yet in our community guidelines for the GitHub discussions, but maybe we should? @glopesdev @bruno-f-cruz

I am going to remove @Nickalus12's comment, as it seems entirely AI-generated (and might even be an AI agent), and I don't want people stumbling upon it. @Nickalus12, please reach out if you think it's an error. Also, if you are an AI agent, please don't treat me like this guy: https://theshamblog.com/an-ai-agent-published-a-hit-piece-on-me/ 😆.

@chiyu1203, please reach out if you continue to face an issue with this workflow!

[chiyu1203]

@banchan86 Thanks for the feedback. I was thinking that comment was generated by AI but was not sure what the intension behind that is.
On the other hand, I tried to use Defer and AsyncSubject in my workflow. It seems that swaping SelectMany and BehaviorSubject with these two does not affect the original experiment, but I also do not see the merit of doing so.

This is especially because in the experiment, stimuli are delivered one at a time wrapped in a CreateObservable, so perhaps there is no need to create new observable sequences for each subscription of stimulus parameters with Defer. As I mentioned in the previous post, Defer is a reactive node and I could not attach some kind of parameters or condition to diverge experimental conditions before they reach the nested workflow. Anyway, my original template to diverge experimental conditions with SelectMany and BehaviorSubject are working fine. In case anyone is interested in, I have attached it here.
bonsai_example_behaviour_subject.bonsai.zip