You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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?
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!
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.
The text was updated successfully, but these errors were encountered: