Consistent placement for BehaviorSubject properties

[jonnew]

Sometimes they appear in Configure nodes:

https://github.com/neurogears/onix-refactor/blob/481a9150953d1893c916aebb1b0dda721362d527/OpenEphys.Onix/OpenEphys.Onix/ConfigureHeartbeat.cs#L12

Other times they appear in Data IO nodes:

https://github.com/neurogears/onix-refactor/blob/481a9150953d1893c916aebb1b0dda721362d527/OpenEphys.Onix/OpenEphys.Onix/Headstage64ElectricalStimulatorTrigger.cs#L15

Do we want a consistent rule for where they should go?

[glopesdev]

@jonnew I discussed this a bit in #115 but reposting it here for a more general discussion. I think they should go in the configure nodes.

I can see the appeal of dynamic configuration while the device is streaming, but on the other hand I would also expect the configure node to be able to fully configure the sensor even if no downstream data node is immediately used. It also makes it more confusing that settings are distributed across two nodes.

Maybe this is one of the cases where we do want to allow for the configure node to write to the device while the workflow is running (the current architecture allows seamlessly for both online and offline editing), or alternatively we could have an editor that previews the camera for configuration.

[jonnew]

I agree with the argument over having a consistent place to configure hardware operation. However, I would say the main reason for having these real-time properties is so that they can be exposed in a workflow and changed using upstream logic. I guess that's OK because the user should probably be using a shared subject to get the values from some distant part of the workflow to where they are needed in the configuration chain?

If we want to go this way, we will need to do a review of non-configure nodes because there are least a few of them that have real-time properties inside.

[jonnew]

After our meeting the conclusion is the following loose rules:

• By default all properties should probably try to target config nodes
• There is a very weak threshold, however, for moving them to the Source or sink nodes if it "feels right" (e.g. electrical stimulators)
• Another case is when defaults need to be configurable using a GUI. In this case, they must not be exposed as normal properties using the default property pane. The reason being, it looks like the can be edited in the same way from two places. Using a GUI uses Bonsai's run vs configure states to somewhat enforce distinction between the two.