Back to the main page.
Bug 3467 - ft_spike_plot_raster goes not use correct latency
| Status | CLOSED FIXED |
| Reported | 2019-01-08 18:40:00 +0100 |
| Modified | 2019-04-01 08:58:17 +0200 |
| Product: | FieldTrip |
| Component: | core |
| Version: | unspecified |
| Hardware: | PC |
| Operating System: | Windows |
| Importance: | P5 normal |
| Assigned to: | Jan-Mathijs Schoffelen |
| URL: | |
| Tags: | |
| Depends on: | |
| Blocks: | |
| See also: |
Stephen Whitmarsh - 2019-01-08 18:40:13 +0100
Hi there, It seems a bug has been introduced recently, whereby latency is not properly set - it plots maximum trial-length instead of the cfg.latency(2) that was set) because of line 113, that fulls the latency our of the third argument (the spike density): (cfg.latency = timelock.cfg.latency;) This is not desired, at least the deep cfg it should not trump a cfg setting, right? To be clear, commenting out this line recovered the previous functionality for me. Cheers, stephen
Jan-Mathijs Schoffelen - 2019-01-10 14:24:55 +0100
I think that in general it is not good to look into the data.cfg to overrule cfg settings, although in this function it is explicitly mentioned in the documentation setting that it is done. Apparently, my recent fixes in latency handling in the normal fieldtrip functions, allowed this to surface (because it influences your work), and the fact that I popped up in the history of the affected functions I have been added in the CC... I would be perfectly fine with commenting this line out, since it does not seem as if Martin Vinck (the original contributor) is still actively involved in maintenance/support. What do you think, would you dare to generate a Pull request for this? :)