[FieldTrip] cfg.latency and ft_timelockanalysis

[jan-mathijs schoffelen]

Hi Nathan,

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- 
intuitive.

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.

Best wishes,

Jan-Mathijs


On Apr 7, 2011, at 11:31 AM, Nathan Weisz wrote:

> hi,
>
> i just noticed that the option cfg.latency has been deprecated from  
> ft_timelockanalysis.
>
> 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,
> nathan
>
> _______________________________________________
> fieldtrip mailing list
> fieldtrip at donders.ru.nl
> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip

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
Telephone: 0031-24-3614793