dpss window: check units of bandwidth parameter about syncopy

[pantaray]

Thanks for going down the rabbit hole with this one, @tensionhead ! I agree, that manually setting nTaper has great potential to sabotage one's spectral analysis. However, I think we should still provide the possibility to enforce a specific taper count (maybe accompanied by a stern warning message in the terminal). So I'd vote for Option #2: keep nTaper and tapsmofrq but make them mutually exclusive options. Would you be okay with that?

[tensionhead]

Ok I followed through with this as suggested by @pantaray One downside of the new now correct DPSS settings is, that the self-proclaimed sane automatic setting ("3/4 Octave") for tapsmofrq within the specest frontend gives rather large values, like 25Hz. The optimal number of tapers in this case can easily go up to 100 for long (~4000 samples) signals. However this is still correct as shown in this little example plot here (4000 samples, tapsmofrq = 15Hz):

The optimal number of Tapers is 60, and only with this the full (rectangular) desired frequency smoothing bandwidth is realized. Manually setting it to half the correct number (30), rather strongly distorts the spectral estimation.
Technically this question is resolved now, as users can input tapsmofrq in Hz and the rest is taken care off, with the possibility to still use a different number of tapers if desired. So closing this with c8ebf79

[tensionhead]

According to scipy's documentation, it's defined as

'''
NW : float

    Standardized half bandwidth corresponding to 2*NW = BW/f0 = BW*M*dt where dt is taken as 1.
'''

which I agree isn't really clear. It's definitely no 'smoothing frequency in Hz' as it's in the doc right now, as tapsmofrq gets mapped directly onto NW. The actual frequency smoothing is controlled by both Kmax and NW parameters. WE'll probably have to dig deeper to have the same tapsmofrq as in FieldTrip.

[tensionhead]

So tracing this issue on SciPy made me look at the matlab(!) documentation where there is the interesting part:

You can specify the bandwidth of the Slepian sequences in Hz by defining the time half bandwidth product as NW/Fs, where Fs is the sample rate.

So from this we should be able to map SciPy's NW to tapsmofreq.

[tensionhead]

Ok I think I got it, according to the paper: "The Effective Bandwidth of a Multitaper Spectral Estimator, A. T. Walden, E. J. McCoy and D. B. Percival" the number of tapers, the effective bandwidth and the lenght of the signal are of course all connected. From their paper:

Where NW is the product of signal length N and half-bandwidth W, we see that to actual reach a desired bandwidth 2W we have to max out the tapers, but not go over the limit Kmax = 2NW-1 (due to side-lobe minimisation, which otherwise fails and regions far away from actual spectral peaks get amplified) . This also means there is a minimal frequency smoothing bandwidth, given by 2W > 2fs / N. So I propose to implement that in the respective frontends, that means deleting the nTaper option as this doesn't make much sense actually! @pantaray what's your take on this? Alternatively one could make tapsmofreq and nTaper mutually exclusive parameters, with the latter being quite dangerous