I realise there's no added value in having an individual commit per file, esp. for such a simple thing.
A side-effect when editing directly in the web-interface. I created a local copy of my fork and did a rebase, which I'd push to a new fork. How should the commit message look like? It would get rather long, like
"BPF, LPF, RLPF, RHPF, Resonz, BBandPass, BAllPass, BBandStop, BHiPass, BHiPass4, BLowPass, BLowPass4, BHiShelf, BLowShelf, BPeakEQ, BRF helpfiles: added warning about frequencies close to 0.
Related to ce1d223"

wouldn't it be better to fix the filters?

btw, do all those filters show this behaviour? iirc quantisation noise at low frequencies should be mainly a problem for high-pass (and possibly band-pass) filters ...

a good commit message would be "helpfiles: added warning about frequencies close to 0."

no need to list which files, that is easily apparent when looking at the commit.

as tim says, do check that this is the case for all of these. I don't remember having problems with LPF

indeed HP and BP are the ones prone to be screaming. I also tested against abrupt parameter changes which also can cause bad 0dBFs clicks and plops. Others, like SVF don't. Hence the wording.

regarding fixing the filters: I agree, even if it would cause to change behaviour of existing sc-code (IIRC we had that with 3.4 with the change to double-precision, which is something different, I know).
But, I think it's easy to revert this commit once the fix is completed.

@crucialfelix - would the commits in this PR be changed when I push the rebase to the fork or would I have to retract and re-issue?
edit: solved - it's one commit now.