Ow Bass Click

[dpwe]

#628 fixed a nasty click when re-starting a filter from low-frequency state. The fix was empirical and a hack; we need to find out why osc startup depends on the initial values of msynth->filter_logfreq and msynth->resonance.

[dpwe]

So what I found was:

(a) I could make the click go away by, at the point of turning the osc off, setting msynth[osc]->filter_logfreq = 0; AND msynth[osc]->resonance = 0.7;. Of course, frequency at zero means 440 Hz, so this is actually a mid-frequency LPF, with no peaking. I was imagining these are the values picked up by the osc when it next stops BUT...

(b) It turns out that filter_process() is called after the render_osc_wave() call that decides the osc is not AUDIBLE. However, we don't check synth[osc]->status between render_osc_wave and filter_process, so we will call the filter_process one last time even after deciding the osc is done. Although the oscillator input here is zero (? should be, that's what max_val is checking, and we only terminate AUDIBLE when max_val is zero for several blocks, the filter can still be "ringing out" its state. What's notable here is that this last call happens after we modify the filter center frequency and resonance - suddenly the filter is not so ring-y, so it damps down the remaining energy within that single frame.

(c) I was focused on the click at the start of the following note. I noticed there was also a click at the abrupt termination of the preceding note, but I decided to ignore that. BUT turns out they are linked - the click at the start of the next note is somehow the delayed filter output from the end of the previous note. Consider these two screen shots, the top one is the click-free version with the msynth fixes, and the extra call to process filter. The lower one is when I "fix" things, so there's no extra call to filter_process AND I zero-out the filter state (instead of the msynth mods).

Notice that the click at t=0.604 in the lower pane is kinda like the nice little rolloff at the termination of the previous note at t=0.581 in the top pane.. but delayed by 23 ms (and a bit distorted).

The nonzero state from (a) and (b) is somehow vital to the smooth start of the next note, which is why zeroing the state in (c) messes up the smooth start. But that click I think also comes from some kind of residual state that has been worked out by the final frame output due to the extra filter_process.

The contrast is the very first onset, which does not have the click, presumably because it has both truly zero state and nothing left over from any preceding note. However, inspecting some values from its oscillator input too, it's not quite identical.. maybe something to do with mfreq[osc]->last_amp?

I still haven't sorted this out, and I'm very suspicious that I haven't captured everything I think I have in filter state. But this is all I have for now.

[dpwe]

Investigating further, I preserved the 'one extra filter frame' behavior (b), but then cleared the filter state after that frame had basically damped-down the filter output; the behavior looked the same as the "good" version (top frame), although the values were a little different (rel diff -87.8 dB). But if I took away the make-the-filter-damp-y (a), the clicks both came back - the filter wasn't damp-y, so kept ringing through the extra frame, and that unterminated state showed up at the start of the next note when the osc restarted.

There's got to be something in the osc state that is not getting cleared, that's persisting through the period of inactivity. And it's got to be in the filter, since letting the filter damp-down fixes it. Evidently, resetting the filter isn't clearing everything I think it's clearing.

I even separated synthinfo params (things set by the user, that don't otherwise change) and state (things updated as the note evolves) and gave them separate reset functions so I can reset_osc_state when I reset_modosc. Does not stop the glitch at the start of the following note!