Why is an InputMapping required to isolate properties inside a SelectMany from subsequent inputs?

[ablot]

I'm not sure how to phrase the question, so an example is probably the simplest. If I have a SelectMany with a sequence of inputs (here a ParameterRange of locations for some visual stimulus) like that:

I want to have a grating per value of the ParameterRange. If I simply use a PropertyMapping after externalising LocationX, all gratings end up at the last value of the range. If I use a WithLatestFrom and an InputMapping, things work as expected. So on this screenshot the top version works, the bottom version doesn't.

I have no clue why and I keep on having bugs in my workflows that are probably related to the fact that I don't understand this. I read the part about property and input mappings on the website but that didn't make it clear.

I expected each input to the SelectMany to create one observable which will get exactly 1 notification out of the Source1 (the current value of the ParameterRange). It seems to be true, as I can publish the input in an AsyncSubject and use it, which means the observable completed after this single element (I think).

Yet when the subsequent input reaches the SelectMany the new grating shows as expected in the new position but the previous grating, which had been created with this now completed AsyncSubject get its LocationX property magically updated and moves to the same place 🤯 . Is the subject (X in this case) somehow shared between all observables created by the SelectMany? And if so, why does the InputMapping avoid the issue?

The full test workflow I used: property_magic.bonsai.zip

[bruno-f-cruz]

Heya

DrawGratings uses a shader to draw stuff on the screen. Even if you create N parallel observables (via SelectMany) this shader will still be shared across all calls. The way you update a variable in the shaders (say, color) is by writing to uniforms that can be changed from UpdateUniform anywhere in your workflow (you will find some inside DrawGratings).
The externalized property "bug" you are describing is expected under the default scenario where each SelectMany sets its own value in the property when they start (i.e. in the first frame), but once they are done setting, the last value of the property will be the one that "stays" in the shader for all subsequent RenderFrame events.

How do we get around this? We force the property to update on EVERY RenderFrame event. This is effectively what InputMapping is doing. Instead of setting the property once and forgetting about it, InputMapping uses each input event to "reset" the property value to the one stored in the Subject on each frame.

I should say that this behavior can be substantially different across Bonsai operators depending on the underlying implementation of the operator. For instance, in some nodes, the initial property will get used forever (e.g., DueTime in Timer) despite how many times you try to change it, and you would not observe the sort of behavior you are describing. Others, like "Multiply", will take the new property and update their internal computation.

These are two extreme cases, but since properties are updated asynchronously from the Observable OnNext method, having a way to classify all possible behaviors is a bit daunting. As a result, I encourage you to be systematic/explicit about the behavior you expect. In this case, InputMapping is one way to go about it, by saying: "I want the shader uniform to be updated at the same time as the frame is about to render". However, in other situations, I really want to be truly event-driven (e.g., updating the pitch and volume of a sound from two different asynchronous sources).

Anyway, hope it helps :)

[ablot]

Thanks a lot. It all makes sense now!

If the shader is shared, does that mean that I need to be somewhat careful if I edit things inside the DrawGratings to avoid race conditions between the observables running in parallel or is everything fine and sorted out somehow by bonsai/opengl/someone?