Back to the main page.
Bug 975 - ft_freqanalysis should support variable number of tapers per trial for cfg.method='mtmfft'
| Status | CLOSED FIXED |
| Reported | 2011-09-22 10:32:00 +0200 |
| Modified | 2012-02-01 13:48:53 +0100 |
| Product: | FieldTrip |
| Component: | specest |
| Version: | unspecified |
| Hardware: | PC |
| Operating System: | Mac OS |
| Importance: | P1 normal |
| Assigned to: | Roemer van der Meij |
| URL: | |
| Tags: | |
| Depends on: | |
| Blocks: | |
| See also: |
Jan-Mathijs Schoffelen - 2011-09-22 10:32:16 +0200
Somehow this functionality has been lost along the way. I made a fix: Roemer could you go over it and check whether this is the way to do it? See also fieldtrip/test/test_bug905.m and the correspondence in bug 905
Roemer van der Meij - 2011-09-22 13:11:36 +0200
I wasn't sure whether the error lied in freqanalysis, I just meant it did not officially support it, but after your reply I think I must have been thinking of mtmconvol. Freqanalysis ran fine with the variable taper numbers for mtmfft in the testscript. Freqdescriptives however, was the one giving the error. I just noticed Eric's data should not have a different number of tapers anyway, and considering I thought mtmfft and a variable ntaper were not supported, I thought the issue was fixed (as the input data was faulty to begin with). However, if mtmfft supported it from the beginning anyway, the error lied in somewhere in the freqdescriptives tree. But..... since your change in ft_freqanalysis, ft_freqdescriptives doesn't result in an error anymore in Eric's script, so apparently something went wrong, and something was fixed ;o. But... what was it? On a similar note, the cumtapcnt field is now wrong. It only consists of one number per trial for mtmfft, whilst it should now most definitely be a vector. I remember we made a choice at some point to do it like this, are you sure we supported var-ntaper in the past?