Structs

Represents a bunch of min/max samples. Usually copied from the MonitorProcessor thread to the frontend if required.
The actual frontend API for the MonitorProcessor. We start an extra thread for handling monitored signals from the MonitorBackend, because we can’t guarantee that the UI thread is actually started or working. Also because we want to be independent of whether a UI is started at all.
This structure holds the output of the 6 cell inputs and outputs that is currently being monitored by the frontend.
Implements the logic for min/maxing a single signal channel/line.
Coordinates the processing of incoming MonitorBufs.

Constants

Just some base to determine the monitor buffer sizes.
Maximum number of monitor buffers to hold in the backend. Typically there are only 16-32ms of monitor content floating around, as the monitor processing thread regularily processes the monitor.
The number of audio samples over which to calculate one min/max sample. Typically something around 750.
The length in seconds of the MONITOR_MINMAX_SAMPLES
The number of minmax samples to hold.
The sleep time of the thread that receives monitoring data from the backend/audio thread. It should be within the time of a frame of the UI thread for smooth updates. The maximum is thus about 16ms. The processing of the audio buffer is somewhere in the us area.
3 inputs, 3 outputs of signal monitors.

Traits

A trait that represents any kind of monitorable sources that provides at least MAX_BLOCK_SIZE samples.

Functions

Creates a pair of interconnected MonitorBackend and MonitorProcessor instances, to be sent to different threads.

Type Definitions

Pointer type for the MonitorBuf