[FieldTrip] cfg.latency and ft_timelockanalysis
jan.schoffelen at donders.ru.nl
Thu Apr 7 14:14:10 CEST 2011
Yes, we thought long and deep about this, and we concluded that
cfg.latency was to be kicked out as an option. We had the impression
that the old-style cfg options were a bit confusing and counter-
First of all, apologies that we did not communicate this change more
clearly, we kind of assumed that hardly anyone used this option anyway.
This is our take on it:
If you use ft_timelockanalysis in order to compute a covariance to be
used in ft_sourceanalysis, cfg.covariancewindow is the option that
specifies the latency for the covariance. A call to
ft_timelockanalysis will then give you the event-related field for
free, but the latency of this ERF is not anymore confined (which was
previously done by cfg.latency). What we thought was confusing (and
potentially unwanted), is that the user could specify totally
different windows for the covariance computation and for the latency,
which could lead to the spatial filters being optimized for a stretch
of data totally different from the source-reconstructed data the user
would be looking at after the call to ft_sourceanalysis.
It is the covariancewindow that eventually determines the shape of the
spatial filters and the idea was that one could just as well project
the whole ERF through the spatial filters and apply latency
constraints later on, if necessary. This functionality (i.e. the
application of latency constraints is not yet fully operational, but
we're working on it).
If the user would like to do some fancy stuff (which you seem to
like ;o) ) we'd rather make it explicit that ft_sourceanalysis needs
to be run twice (in the first round obviously with cfg.keepfilter =
'yes'), instead of running the risk that the user doesn't fully obtain
what he/she asked for.
Obviously, the scenario you sketch is perfectly valid and we
understand that you like it to still be supported. We however hope
that you appreciate the fact that we trust our expert users to take
this little inconvenience for granted at the benefit of more
transparent code and less trouble for the novice users.
On Apr 7, 2011, at 11:31 AM, Nathan Weisz wrote:
> i just noticed that the option cfg.latency has been deprecated from
> does this have a specific reason? seems to be done on purpose :-)
> i am asking because i always thought that it was a nice feature when
> later using beamformer analysis (lcmv) to have a more narrow window
> to calculate e.g. power (using ft_sourcedescriptives) or to orient
> sources when later applying filters to raw data, and to have a wider
> window including also prestim periods for covariance estimation.
> of course the workaround is to run two timelocks with a
> redefinetrial in between. but it appears rather awkward.
> thanks for any input,
> fieldtrip mailing list
> fieldtrip at donders.ru.nl
Dr. J.M. (Jan-Mathijs) Schoffelen
Donders Institute for Brain, Cognition and Behaviour,
Centre for Cognitive Neuroimaging,
Radboud University Nijmegen, The Netherlands
J.Schoffelen at donders.ru.nl
More information about the fieldtrip