Currently we have measurements and statistics. Measurements are regular filters with a flag that allows the option of not displaying them directly, but instead displaying their statistics. Statistics are of filters, and each statistic is a scalar that remember some history about the filter they are a statistic of through time. Many measurements are per-cycle of an AC waveform, for example the FrequencyMeasurement. Then min, average, and max frequency for the whole waveform (and some history) can be viewed by looking at the statistics for the FrequencyMeasurement.
However, there's some stuff that's kind of ambiguous. The motivating example is wanting a simple SNR measurement. (More design question ticket text than code!) It's not necessarily well-defined to compute average SNR as (unweighted) sum of cycle-wise SNR measurements. We can calculate SNR of a whole waveform as a filter that outputs a waveform with only one point, but that leads to weird UX since displaying it is pointless (ha ha!) Displaying only it's statistics is also weird UX since min = max = average when there is only one point (ignoring history behavior.) It's also weird since (in my opinion) I don't think of the SNR as it's own waveform to view stats of, but as a stat of the initial waveform.
One option is to integrate it as a single-point measurement (or a cycle-wise measurement with an option for single-point.) This has the aforementioned UX challenges.
The other option is to integrate it as a statistic. This requires dealing with the hardcoded statistic instantiation code from the UI (which currently only instantiates Min, Max, Avg) and allowing statistics to output units other than the input waveform unit. It might also be confusing if only some statistics have history behavior (though the SNR statistic could grow history behavior.)
The third option is to pursue some more general unification of the statistic and few-or-single point waveform concepts. Not sure what this would look like.
For reference, here is what I have locally with some hackjob patching, which is my preferred UX:
Currently we have measurements and statistics. Measurements are regular filters with a flag that allows the option of not displaying them directly, but instead displaying their statistics. Statistics are of filters, and each statistic is a scalar that remember some history about the filter they are a statistic of through time. Many measurements are per-cycle of an AC waveform, for example the FrequencyMeasurement. Then min, average, and max frequency for the whole waveform (and some history) can be viewed by looking at the statistics for the FrequencyMeasurement.
However, there's some stuff that's kind of ambiguous. The motivating example is wanting a simple SNR measurement. (More design question ticket text than code!) It's not necessarily well-defined to compute average SNR as (unweighted) sum of cycle-wise SNR measurements. We can calculate SNR of a whole waveform as a filter that outputs a waveform with only one point, but that leads to weird UX since displaying it is pointless (ha ha!) Displaying only it's statistics is also weird UX since min = max = average when there is only one point (ignoring history behavior.) It's also weird since (in my opinion) I don't think of the SNR as it's own waveform to view stats of, but as a stat of the initial waveform.
For reference, here is what I have locally with some hackjob patching, which is my preferred UX:![image](https://user-images.githubusercontent.com/2013596/215922995-67a61ce3-d3b3-4b31-aca5-81d63e914afd.png)