Structure¶
vortex provides several categories of objects: drivers, components, and the engine. This document provides an overview of these objects.
Drivers¶
Drivers provide convenient wrappers around low-level APIs. Examples include drivers for NI DAQmx, Alazar ATS-SDK, and Reflexxes. Applications that use vortex do not routinely interact with drivers except for use of configuration constants or introspection. For example, an application may query available Alazar cards via the Alazar driver.
C++
C++ users of vortex may provide their own drivers for custom components, such as a new acquisition card.
Components¶
Components encapsulate functionality that meets the requirements of specific roles within vortex.
Examples include alazar_acqusition_t
, which encapsulates an acquisition from an Alazar card, or cuda_processor_t
, which encapsulates CUDA-based OCT processing.
Each component is paired with a configuration object which contains all information necessary for a component to operate.
For example, processor_config_t
indicates the A-scan shape and spectral filter for use with cuda_processor_t
.
C++
C++ users of vortex may provide their own components, optionally extending existing ones.
Python
Python users are limited to the standard vortex components.
Engine¶
The Engine implements a flexible pipeline that organizes components into an application and manages data transfer between components. Components within a particular stage of the pipeline meet specific requirements and interface with the engine via an adapter. A typical use-case is to configure and start the engine such that vortex manages the majority of the data processing.
C++
C++ users may wish to implement a custom pipeline rather than using vortex’s engine in order to meet specific application needs.
Python
Python users interact primarily with vortex at the engine level by configuring a pipeline.