Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Times propagation to preprocessing and other modules #3534

Open
JoeZiminski opened this issue Nov 13, 2024 · 2 comments
Open

Times propagation to preprocessing and other modules #3534

JoeZiminski opened this issue Nov 13, 2024 · 2 comments
Labels
core Changes to core module

Comments

@JoeZiminski
Copy link
Collaborator

JoeZiminski commented Nov 13, 2024

At the moment as I understand it set times do not predictably propagate to preprocessing steps, (i.e. I think some use them but some dont, this has come up in #3509 and #3519). In general I am not certain what areas of the codebase they have been extended to (e.g. off the top of my head I guess this is not really needed for preprocessing? I'm not sure the status of all the different widgets).

I think there are two approaches, as extending times throughout the codebase is a big job (?). One is to really reduce the scope of times, make it settable on the sorting object only and very explictly state that it is only used for setting the spike times after sorting, which I think is the main use case. The other is to 'audit' all preprocessing, postprocessing steps and widgets to check if timings are required. Having a quick look, maybe it is not so bad, not many preprocesing steps at least explicitly use time periods, and where they do they take the frame e.g. silence periods. Many use time parameters e.g. margin_ms but as long as there is a sampling rate the absolute times don't matter @h-mayorquin I think this means we will always have to have a sampling rate of some kind, e.g. as the average rate for non-evenly sampled data.

Anyways, I don't have time to do this 😅 but just raising so it is on the radar, as I think this is quite confusing for users, and also to get some clarify for myself on where times are / arn't used.

@h-mayorquin
Copy link
Collaborator

The other is to 'audit' all preprocessing, postprocessing steps and widgets to check if timings are require

Yeah, maybe not that thorough but we can brainstorm in the maintenance meeting 5-10 minutes which routines might require it and if people agree start working on those ones. I am pretty sure that would give us a better picture of the situation once we start with a specific implementation in a well agreed problem. What do you think?

@JoeZiminski
Copy link
Collaborator Author

I think that's a good way to start, it will make concrete the kind of issues we might face and cases in which the times are needed. At some point it would be useful to go through every step with a fine-tooth comb, as I'm sure there'll be some 'gotchas' lurking there we will not realize. But for sure this is a better way to get going, I'll add it to the meeting itinerary!

@alejoe91 alejoe91 added the core Changes to core module label Nov 21, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
core Changes to core module
Projects
None yet
Development

No branches or pull requests

3 participants