Add generalized acquisition device and associated "hardware source" class

[cmeyer]

Notes from my generalized acquisition device plans.

A generalized acquisition device would be a device that could produce one or more streams of data in various arrangements. The idea is to eliminate the need for device implementers to subclass or implement their own HardwareSource (considered to be an internal class).

Examples would be:

• Frames of 1D or 2D data (e.g. camera)
• Streams of 2D data (e.g. scan)
• Sequences of frames (e.g. camera with fixed number of frames)
• Synchronized frames (e.g. camera synchronized with a scan)
• Bursts of frames (e.g. sequences of frames at regular intervals)
• Multiple channels of output.

The device would include control panels with components specific to the device to control the behavior.

A rough idea (see my local file AcquisitionDevice.py):

class ModeController(typing.Protocol):
    # is_continuous
    # is_interruptable?

    def begin_mode(self) -> None: ...

    def continue_mode(self) -> None: ...

    def end_mode(self) -> None: ...

    def cancel_mode(self) -> None: ...

class AcquisitionDevice(typing.Protocol):
    # device properties

    def close(self) -> None: ...

    def enter_mode(self, mode_name: str, mode_parameters: ModeParameters) -> ModeController: ...

Loose instructions to test a potential implementation

• Define a device interface that supports your physical device, your simulator, and a Python-only simulator as concrete implementations. This will also define the types of data that the devices can produce. We can combine multiple devices together if that makes sense (i.e. scan + camera).
• Implement a HardwareSource (see the protocol in the existing code) for use in live/view-mode image or spectra updates.
• Implement a data stream for use in extended acquisitions such as SI that support partial data updates and may involve multiple devices.
• Implement control panels to launch view modes and extended acquisitions. We may be able to define components to make this easier - Nion can maintain the general acquisition panel; you will implement specific components.
• Implement configuration settings dialog where necessary.
• Implement specific components to fit into the new Swift acquisition panel where possible. This is a work in progress and eventually may eliminate some of the control panels that you have.

Note: original discussion personal notes on 2022-02-15

[cmeyer]

• 86

• 103

• 129

[cmeyer]

Private discussion:

• https://github.com/nion-software/nion-instrumentation/issues/281

[cmeyer]

Also:

• 131