Frequency Tracker mode for inputs

[trentgill]

This feature request is driven by wanting to replace my in-house calibration module with a generic (and sharable) solution.

Basic concept is there is an input mode (ie input[1].mode('frequency')) which counts rising-zero-crossings (with hysteresis). When the pitch has settled on a new frequency (using a fixed window averager) a callback event is called in lua, reporting the detected frequency.

This can be useful for doing musical analysis on a received audio signal, rather than just a control voltage. Perhaps some utility for working with external hardware that doesn't have a CV output, eg: capture and process the pitch of a vintage analog synth, adding harmonies.

For calibration, the first output is sending an output voltage (say 0V). This voltage is sent to the v8 input of the module under test, it's output (square wave preferable) is fed back into crow's input. After the pitch is detected, it is saved in a global, then the voltage is incremented by 1V, and the process repeats. testing can operate over n-octaves, and the received frequency can even be compensated by a static offset to ensure the tracking is performed, centered around some specific frequency. In oscillators, this means you could calibrate based on the 7-octave range 50Hz-3.2kHz, if you wanted to guarantee certain tracking in that region.

The output collected is absolute frequency at the given output voltage, resulting in N-values. These could be processed into their % difference from the expectation (based on the central frequency multiplied by the expected ratio). Overall correlation between expected & measured could be output on output[2]. High-frequency tracking could be available on output[2], displaying the relative % difference in the top 1 or 2 octaves, for devices that provide an HF tracking trimmer. output[3] could be a configurable 'in-range' output that goes high when the calibration has succeeded the tests -> plug this into a VCA over an oscillator to create an audible 'success' tone.

//

If the detection should report an average pitch of a streaming basis (not change-events), the time-window-average-size should be configurable to allow the scripter to prioritize accuracy vs latency as well as introduction of slew.

[trentgill]

I read a note somewhere about saying you get better accuracy / jitter by counting "time between ticks" rather than "ticks per window", which makes a lot of sense. The question is can we get a good measurement of this without having to dedicate a timer to it? Maybe it's ok to dedicate a timer to it! It seems a reasonable thing for freq-detection to use a timer.