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

Add timing metadata for SpikeGLXRawIO #1609

Open
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

h-mayorquin
Copy link
Contributor

Should close #1607

@h-mayorquin
Copy link
Contributor Author

I had a discussion with Graham Findlay from the Tononi and Cirelli lab and he suggested to make the smallest t_start the reference point (hence, it would be 0). That seemed like a good idea to me but I wanted to check with you guys @alejoe91 @samuelgarcia.

@samuelgarcia
Copy link
Contributor

Thanks for this. This is really cool. We should have done this from the beginings.
Maybe we could have an option to force the previous behavior (t_start=0 everywhere) in case some people handle event with this in mind for bawkard compatibility.

forcing the very first t_start to be 0 is convinient sometimes (I did for for some readers).
For long term data conversion the original t_start is better ?
Maybe we could have a secondary option for this ...

@h-mayorquin
Copy link
Contributor Author

h-mayorquin commented Jan 7, 2025

Thanks for this. This is really cool. We should have done this from the beginings.
Maybe we could have an option to force the previous behavior (t_start=0 everywhere) in case some people handle event with this in mind for bawkard compatibility.

I believe adding an option as a temporary solution is acceptable, but it should ultimately be removed to minimize maintenance overhead. Here’s my proposal:

Introduce a boolean flag that allows users to enable the old behavior. However, this flag should also trigger a deprecation warning, informing users that the feature will be removed in the next major release.

forcing the very first t_start to be 0 is convinient sometimes (I did for for some readers).
For long term data conversion the original t_start is better ?
Maybe we could have a secondary option for this ...

I think this purpose would be better served by having a general function or boolean option at init that can be used for any reader. This will be easier to maintain, more ergonomic for the user and I think more useful. What do you think?

@h-mayorquin h-mayorquin closed this Jan 7, 2025
@h-mayorquin h-mayorquin reopened this Jan 7, 2025
@alejoe91
Copy link
Contributor

alejoe91 commented Jan 8, 2025

Thanks for updating this @h-mayorquin

I'm not sure we need the boolean option to force t start at 0...as we're making a new minor release, a small API change as this one is ok. Let's document it properly in the release notes @zm711

@samuelgarcia
Copy link
Contributor

Introduce a boolean flag that allows users to enable the old behavior. However, this flag should also trigger a deprecation warning, informing users that the feature will be removed in the next major release.

Lets forget about it, this useless and painfull work.

I think this purpose would be better served by having a general function or boolean option at init that can be used for any reader. This will be easier to maintain, more ergonomic for the user and I think more useful. What do you think?

Yes. this should be a hack in the main class but then we should not reset the first t_start to 0 then.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Multi-gate and multi-trigger t_starts in SpikeGLX are incorrectly set to 0
4 participants