Docs improvement

[BalzaniEdoardo]

Docs may benefit from interactive visualization, for instance:

• in the filtering, we could have a slider that changes the transition banwidth, and the plot showing how this changes the psd of the filter as well as the filtered output.
• In the wavelet tutorial, one could dynamically set the number of wavelets, or other hyperparameters and see the result in real time (like changing the normalization etc.)

This would require adding notebook and ipywidgets in the docs dependencies (maybe also jupyterlab_widgets, nbformat?)

[gviejo]

Adding Billy's comment here :
Tutorial:

• Could be nice to have some high-level description here: why is filtering used in neuroscience, with link to examples (including another of pynapple's tutorials!). And when would one use bandpass/lowpass/etc
• The question of how should one choose sinc vs. butter isn't addressed. they do give different outputs: is that important? or is the choice largely about efficiency?
• Same with how to choose the cutoff, order, and transition_bandwidth parameters. cutoff depends on the user's scientific question (but that should be said explicitly), and guidance on the others would be nice.
• when plotting the results of the bandpass filter, both filters reduce the amplitude of the signal in the beginning. why is that? and why not show the full 2-second signal?
• also the x-axis on that plot is labelled Time (Hz), it should be Time (s), right?
• The frequency response plots are confusing -- took me a while to realize the top and bottom rows are the same plots, just with linear and log scales on the y-axis. it's also not clear what users should be taking from this plot.
  • To make it more useful: could show these filters applied to the signal (both the time and frequency domain representations) and talk through why you might want sharper / less sharp of a transition.
  • Is there a principled way to choose values for order / transition bandwidth, or is it empirical? you give some defaults, do those work in most cases or should people always experiment with them?
• The reference to "kernel is too short" is confusing, since the user never sees the actual kernel. I would mention that in an aside (footnote or admonition) and point out what effect that has in the data (reduction of signal amplitude), and how the user should fix it (reduce transition bandwidth).
  • This should be its own section, it's kind of "troubleshooting"
• The performance code block is really long and not actually interesting to the user. it would be nice to hide this. what we ended up doing in nemos was moving the utility code to a hidden module. could do that or, since users probably won't run this themselves, could just move it to a utility script in the docs folder.
• that performance section should also interpret the output. why are there two plots here? what are we supposed to take from this?
• is it worth removing the noise from the example signal? or at least, do it with and without? real data always has noise, but it would make interpreting the bandstop filter easier if the noise wasn't present. the noise also means the true 10 Hz component and the outputs of the filters are different, which might confuse people. should at least explain this.