endolith

Possibly fixed in https://github.com/endolith/waveform-analyzer/commit/12325d50171e66871dae50c1b8142174471e703b?

@pavlos163 Have you tried it since I fixed the bug in HPS?

https://drive.google.com/drive/folders/1mvybLleH5gvskzoBYj1TlgxTHTeebf_9?usp=sharing

https://github.com/endolith/waveform_analysis/issues/22

Are you feeding a zero-length array to `freq_from_hps()`? `freq_from_hps(array([]), 48000)` does the same thing?

SciPy uses FFTPACK which is optimized for multiples of 2, 3, 5, which I made a function for here: https://github.com/scipy/scipy/pull/3144 The function is _next_regular https://github.com/endolith/scipy/blob/master/scipy/signal/signaltools.py#L246 but planning on changing it...

> So this will this end up in numpy.fft.rfft() and then it will just always be fast? No, but czt can replace prime-length ffts in the future > Oh, or...

actually I'd be happier if next_regular were just copied into common.py as a public function instead of importing a private name that only exists in certain scipy versions and won't...

Now it's [a public function `next_fast_len`](https://github.com/scipy/scipy/blob/master/scipy/fftpack/helper.py#L51).

I don't think this code will work as written. Have you tested it before and after with known frequencies? The new FFT length will be `next_fast_len(N)`, but you're still using...