Auto-estimate margins based on freq_min/f0+Q for filters

[alejoe91]

@samuelgarcia let's discuss!

[yger]

I think this is a great feature, but I already told @samuelgarcia that maybe we should at very least warn (prevent ?) users that will use very low frequencies for filters, trying to get LFP and/or low pass versions of the data. If the automatic margin starts to be really large (maybe larger than the default chunk size of 1s), then we should warn users that they are doing something clearly suboptimal.

[alejoe91]

I think this is a great feature, but I already told @samuelgarcia that maybe we should at very least warn (prevent ?) users that will use very low frequencies for filters, trying to get LFP and/or low pass versions of the data. If the automatic margin starts to be really large (maybe larger than the default chunk size of 1s), then we should warn users that they are doing something clearly suboptimal.

Sub-optimal but somehow needed! Maybe we can warn if the margin is greater than the max_margin_s (default 5 s). What do you think?

[yger]

Yes, I've read the PR, and indeed, at least a warning that the theoretical margin should be XX, and that it has be clipped to max_margin_s. The thing is that if users really want to do that, then the warning message could also advise them to increase chunk_duration in the default_job_kwargs, to reduce IO overloads

[samuelgarcia]

Not sure I like this concept of max margin...
We really should prevent users to use spikeinterface for lfp low frequency purpose.

[alejoe91]

We have to use it! For wideband signals, there is no way around. You have to extract LFP on chunks. Extending the margin will minimize the error and the max margin is a tradeoff between accuracy and performance.