Back to the main page.
Bug 654 - update functions using legacy trl matrix to use sampleinfo (and offset) instead
| Status | CLOSED FIXED |
| Reported | 2011-05-11 11:58:00 +0200 |
| Modified | 2011-07-13 14:20:24 +0200 |
| Product: | FieldTrip |
| Component: | core |
| Version: | unspecified |
| Hardware: | PC |
| Operating System: | Windows |
| Importance: | P1 normal |
| Assigned to: | Eelke Spaak |
| URL: | |
| Tags: | |
| Depends on: | |
| Blocks: | |
| See also: |
Eelke Spaak - 2011-05-11 11:58:19 +0200
E.g., ft_rejectvisual ft_rejectartifact ft_databrowser and quite possibly others.
Robert Oostenveld - 2011-05-11 13:29:49 +0200
also rename ft_checkdata's hastrialdef to hassampleinfo
Robert Oostenveld - 2011-05-11 13:31:36 +0200
hassampleinfo should have levels yes, no, ifmakessense
Eelke Spaak - 2011-07-04 11:25:09 +0200
Would the following work for the 'ifmakessense' option?: - See if trl-matrix present somewhere in the cfg-tree; - If not: don't add sampleinfo - If yes: check cfg-tree if ft_resampledata has been called - If no: copy from trl - If yes: don't add sampleinfo The hassampleinfo:'yes' option would remain the same as currently with hastrialdef: if no trl-matrix present, attempt to recreate the sampleinfo by assuming the trials are segments of a continuous recording.
Jan-Mathijs Schoffelen - 2011-07-04 12:00:32 +0200
We actually want to get rid of looking into the cfg-tree. this was once included for backward compatibility, but at some point we need to take the decision to not look into the cfg anymore.
Eelke Spaak - 2011-07-04 12:17:58 +0200
(In reply to comment #4) > We actually want to get rid of looking into the cfg-tree. > > this was once included for backward compatibility, but at some point we need > to take the decision to not look into the cfg anymore. That seems like a very good idea :) However, then I don't see any automatic way of having ft_checkdata determine whether it would make sense to add sampleinfo. Do either of you? Else we could just keep the option at levels yes/no.