Determine which actions should be written in real-time

[bparks13]

Currently the working paradigm is to collate all hardware changes, and only write to the hardware when acquisition is started. While this is a good method for Neuropixels devices, where shift registers take a long time to write, it is not necessarily the most useful for very small writes. A relevant example is the AnalogIO, where the channel can be either input or output, and changing the direction in software should be immediately reflected in the hardware LED.

Separate out which writes are going to be quick (i.e., non-blocking and no need for a background thread to write changes) from longer writes which will need to be blocking.

Blocking

All Neuropixels devices

• Here, we should also add some concept of state, so that if no changes have been made to the settings since the last time they were written, there will not need to be a whole write
• Additionally, add a button in the settings tabs that allows the user to upload the settings whenever they wish, regardless of acquisition state

Non-Blocking

All other devices?

[aacuevas]

There is a potential corner case that we need to address. If a headstage were to lose power (e.g. by accidentally flipping the breakout switch) while a context is open but not acquiring, any configuration done on it would be lost but the software would not know about it, so it would silently start acquisition with wrong settings. If real-time configuration was implemented, we'd need to somehow monitor for this case.