Back to the main page.
Bug 2947 - Not suppressing label-input
| Status | CLOSED FIXED |
| Reported | 2015-08-20 12:52:00 +0200 |
| Modified | 2016-06-14 16:14:52 +0200 |
| Product: | FieldTrip |
| Component: | core |
| Version: | unspecified |
| Hardware: | PC |
| Operating System: | Windows |
| Importance: | P5 normal |
| Assigned to: | Robert Oostenveld |
| URL: | |
| Tags: | |
| Depends on: | |
| Blocks: | |
| See also: |
- 2015-08-20 12:52:09 +0200
I'm using the latest version of FT (located at '/home/common/matlab/fieldtrip') in combination with Matlab version 2014a. Now, for (almost) all functions I call the label input is not suppressed. Example: I call some FT-function and the command window shows: the input is freq data with 270 channels, 1 frequencybins and no timebins label = 'MLC12' 'MLC13' 'MLC14' 'MLC15' 'MLC16' 'MLC17' 'MLC21' 'MLC22' .... and all other MEG-channels Calling multiple FT-functions within a script causes my entire command window to fill up with labels, and makes it hard to see the crucial information.
Robert Oostenveld - 2015-08-20 13:08:19 +0200
(In reply to e.tewoerd from comment #0) it sounds as if somewhere in the code there is a ";" missing at the end of the line.
Robert Oostenveld - 2015-08-20 13:16:18 +0200
I can NOT reproduce with my development version, see below >> cfg = []; >> cfg.dataset = 'ArtifactMEG.ds'; >> data = ft_preprocessing(cfg) ... snip... processing channel { 'STIM' 'SCLK01' 'BG1' 'BG2' 'BG3' 'BP1' 'BP2' 'BP3' 'BQ1' 'BQ2' 'BQ3' 'BR1' 'BR2' 'BR3' 'G11' 'G12' 'G13' 'G22' 'G23' 'P11' 'P12' 'P13' 'P22' 'P23' 'Q12' 'Q21' 'R11' 'R12' 'R13' 'R22' 'R23' 'MLC11' 'MLC12' 'MLC13' 'MLC14' 'MLC15' 'MLC21' 'MLC22' 'MLC23' 'MLC24' 'MLC31' 'MLC32' 'MLC33' 'MLC41' 'MLC42' 'MLC43' 'MLF11' 'MLF12' 'MLF21' 'MLF22' 'MLF23' 'MLF31' 'MLF32' 'MLF33' 'MLF34' 'MLF41' 'MLF42' 'MLF43' 'MLF44' 'MLF45' 'MLF51' 'MLF52' 'MLO11' 'MLO12' 'MLO21' 'MLO22' 'MLO31' 'MLO32' 'MLO33' 'MLO41' 'MLO42' 'MLO43' 'MLP11' 'MLP12' 'MLP13' 'MLP21' 'MLP22' 'MLP31' 'MLP32' 'MLP33' 'MLP34' 'MLT11' 'MLT12' 'MLT13' 'MLT14' 'MLT15' 'MLT16' 'MLT21' 'MLT22' 'MLT23' 'MLT24' 'MLT25' 'MLT26' 'MLT31' 'MLT32' 'MLT33' 'MLT34' 'MLT35' 'MLT41' 'MLT42' 'MLT43' 'MLT44' 'MRC13' 'MRC14' 'MRC15' 'MRC22' 'MRC23' 'MRC24' 'MRC31' 'MRC32' 'MRC33' 'MRC41' 'MRC42' 'MRC43' 'MRF11' 'MRF21' 'MRF22' 'MRF23' 'MRF31' 'MRF33' 'MRF41' 'MRF42' 'MRF44' 'MRF45' 'MRO11' 'MRO12' 'MRO21' 'MRO22' 'MRO31' 'MRO32' 'MRO33' 'MRO41' 'MRO42' 'MRO43' 'MRP11' 'MRP12' 'MRP13' 'MRP21' 'MRP22' 'MRP31' 'MRP32' 'MRP33' 'MRP34' 'MRT11' 'MRT12' 'MRT13' 'MRT14' 'MRT15' 'MRT16' 'MRT21' 'MRT23' 'MRT24' 'MRT25' 'MRT26' 'MRT32' 'MRT33' 'MRT34' 'MRT35' 'MRT42' 'MRT43' 'MRT44' 'MZC01' 'MZC02' 'MZF01' 'MZF02' 'MZF03' 'MZO01' 'MZO02' 'MZP01' 'MZP02' 'jaw' 'neck' 'EOG' 'ECG' 'ADC15' 'ADC16' } reading and preprocessing reading and preprocessing trial 76 from 76 the call to "ft_preprocessing" took 9 seconds and required the additional allocation of an estimated 1275 MB data = hdr: [1x1 struct] label: {176x1 cell} time: {1x76 cell} trial: {1x76 cell} fsample: 1200 sampleinfo: [76x2 double] grad: [1x1 struct] cfg: [1x1 struct] >> ft_timelockanalysis([], data) the input is raw data with 176 channels and 76 trials the call to "ft_selectdata" took 0 seconds and required the additional allocation of an estimated 1 MB averaging trials averaging trial 76 of 76 the call to "ft_timelockanalysis" took 4 seconds and required the additional allocation of an estimated 89 MB ans = avg: [176x12000 double] var: [176x12000 double] time: [1x12000 double] dof: [176x12000 double] label: {176x1 cell} dimord: 'chan_time' grad: [1x1 struct] cfg: [1x1 struct] but I CAN reproduce with the home/common version: >> ft_timelockanalysis([], data) the input is raw data with 176 channels and 76 trials label = 'STIM' 'SCLK01' 'BG1' 'BG2' 'BG3' 'BP1' 'BP2' 'BP3' 'BQ1' 'BQ2' 'BQ3' 'BR1' 'BR2' ...
Robert Oostenveld - 2015-08-20 13:28:03 +0200
hmm, it turned out that the automatic update script for home/common/matlab/fieldtrip, which I have running as cron job on mentat002, was disabled. This is something I must have done more than a one month ago (before my holiday) so the issue must have been there for some time. thanks for reporting, the update is now again done every 10 minutes.