Back to the main page.

Bug 1514 - ft_spike_select should be merged with ft_selectdata

Reported 2012-06-11 14:34:00 +0200
Modified 2016-05-09 08:50:05 +0200
Product: FieldTrip
Component: spike
Version: unspecified
Hardware: PC
Operating System: Mac OS
Importance: P3 normal
Assigned to: Jan-Mathijs Schoffelen
Depends on:
Blocks: 1021
See also:

Robert Oostenveld - 2012-06-11 14:34:38 +0200

as that is the general function for data handling. I don't know how easy it is to merge them, but it has my preference to keep one function for data-handling instead of multiple. Inside that function, it can of course distinguish between various datatypes (raw, spike, freq, timelock, ...) Furthermore, the data handling should in general be done in the subsequent analysis function and not in an intermediate function. E.g. we don't do ft_preprocessing ft_selectdata ft_freqanalysis but rather ft_preprocessing ft_freqanalysis where in freqanalysis you specify the selection to work on (, cfg.trials). The freqanalysis function then calls the helper function ft_selectdata for the actual data handling. Also the user may call the helper function, but in general should not have to. An appropriate reason for the user to call it is if he/she wants to continue analysis in custom code.

Martin Vinck - 2012-06-11 14:42:36 +0200

I thought about that indeed - however the whole section with dimord checking comes first and it would be hard to fit it in there. I also don't know what the plan is with ft_selectdata as there are two implementations and little help on the options. We may simply add the ft_spike_select as a subfunction there and check in the beginning if the datatype is spike and then refer to a subfunction ft_spike_select. There are some things this function should be able to do, e.g. select based on the spike times (latency), trials, channel, I am not sure whether this can all be fitted in. Where would the user do the selection of channels then in this case? Some channels often need to be removed, e.g. from the .nex files, before going to the next ft_spike_maketrials or ft_appendspike level, as they do not contain proper data.

Robert Oostenveld - 2012-06-11 14:57:30 +0200

(In reply to comment #1) Let's discuss this in person next week and not get distracted at the moment. There are more important things to do right now...

Robert Oostenveld - 2014-04-14 20:25:37 +0200

improved the detection of spike data. mac011> svn commit utilities/ft_datatype.m Sending utilities/ft_datatype.m Transmitting file data . Committed revision 9410.

Robert Oostenveld - 2014-04-14 20:30:12 +0200

started implenting handling for spike data. Since spike data has {chan} as possible dimension, this needs to be treated more like {pos} and {rpt}. Changed the time/trial selection for raw data, there might be a potentiall issue still with this due to double selections in the same field. mac011> svn commit utilities/ Sending utilities/ft_selectdata_newer.m Sending utilities/private/getdimord.m Transmitting file data .. Committed revision 9412.

Robert Oostenveld - 2014-04-15 11:57:17 +0200

I extended ft_selectdata_newer so that it also supports spike data. The cfg options it uses for spike data are the same as ft_spike_select (i.e. trials/latency/channel). mac011> svn commit Sending test/test_ft_selectdata.m Sending utilities/ft_selectdata_newer.m Sending utilities/private/getdimord.m Transmitting file data ... Committed revision 9417.

Ian Andolina - 2014-07-22 12:31:47 +0200

Would you now consider this FIXED and therefore usable?

Jan-Mathijs Schoffelen - 2015-09-25 13:53:31 +0200

I'd like to be able to close this one. Do we have some benchmark spike data on the file-server?

Robert Oostenveld - 2015-09-25 13:56:46 +0200

(In reply to Jan-Mathijs Schoffelen from comment #7) I think the best option is to look at the two spike tutorial scripts, which will have spike data at intermediate levels of processing. There are also test scripts (with some data) in contrib/spike/test/

Jan-Mathijs Schoffelen - 2016-03-01 17:05:02 +0100

Taking over from Martin, because not much has happened here over the past years.

Jan-Mathijs Schoffelen - 2016-03-01 17:05:19 +0100

won't fix for now