Save file with configuration properties at the time that the workflow was started that is decoupled from the .bonsai file

[cjsha]

This allows users to know what experimental parameters were used during a given data acquisition session even if the bonsai workflow changes later. Otherwise people won't know what parameters were used and what parameters to use to properly load their data. Also, it's possible bonsai can run a version of the workflow that hasn't been saved yet bonsai-rx/bonsai#2077 which allows the possibility for the user to perform data acquisition without ever saving the parameters for that data acquisition session.

[ChucklesOnGitHub]

I would add that for troubleshooting, it would be helpful to include the library versions at the time of acquisition.

I guess the recommendation to achieve both of these now are to save the workflow after setting the parameters and not change them during acquisition, and save the Bonsai.config in the folder with the data.

[jonnew]

According to @bparks13, this has come up internally within the Bonsai dev team. It seems like the desire is that there should be a checkmark somewhere that when ticked will result in a new folder being created next to the workflow. Whenever the user presses start, a timestamped copy of the .bonsai file is saved in the folder, or something like this.

Update: This is literally what Bruno recommends in the issue that Cris posted, and I agree.

[glopesdev]

@cjsha @jonnew another option is that, similar to Harp dump register mode, we design a way for the context itself to provide its own configuration metadata.

What I am thinking is it might be possible to add a logger node just before StartAcquisition which would ensure the current configured devices and settings are logged, e.g. to a JSON file.

This would be nice to standardise metadata outside of the .bonsai workflow (e.g. to make it easier for python workflows to inspect) and in cases where ONIX recording context might be configured and used multiple times in a single run.

This could be combined with an idea we discussed several times (which I thought we logged as an issue but cannot find anywhere) about explicitly exposing and saving the configured device table, and also with the idea of a general binary logger for raw ONI packets.

[jonnew]

Hey @glopesdev I think all those options sound like nice additions. I guess there are two separate issues (really 3 counting the data saving) here though

1. Generally workflow reproducibly. This is the issue in Consider saving workflow when program starts bonsai-rx/bonsai#2077. I think this one is important because although .bonsai files are kind of hard to parse, they are a really complete description (doubly so since they are ~functional) of how the data that typically sits next to them was produced.
2. Easy to open and parse meta data for this library: yes, that would be a welcome addition. Are you suggesting that there is "logger node" that converts objects it sees to JSON already that we can use or that we would add this feature as either another operator or to the StartAcqusition operator?
3. Saving ONI data: The frame data saver would be a big help. @aacuevas had a functional prototype somewhere I think.