-
Notifications
You must be signed in to change notification settings - Fork 249
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
IntanRawIO: Update support of rhs
files
#1457
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I accidentally removed these booleans during one of my commits
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Missing one more file test folder the rhs--fps
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Bad-copy paste of the test files on my part. I think this should fix the testing portion at last.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This in general looks good for me. We are replicating the structure that we did for #1402. I would go further for the aproach of segregating the two options (as in the suggestion of having two create_one_file_per_signal_dict
insead of one) but these are already in the realm of weak personal preference.
The tests are failing, let's see what's going on and I will read it again but I think this mostly works.
neo/rawio/intanrawio.py
Outdated
@@ -822,13 +914,37 @@ def read_rhd(filename, file_format: str): | |||
] | |||
|
|||
|
|||
def create_one_file_per_signal_dict(dirname): | |||
"""Function for One File Per Signal Type""" | |||
def create_one_file_per_signal_dict(dirname, rhs: bool = False): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Personal preference so your milleagea might vary, I rather have two functions here instead of mixing the two of them with keywords. I prefer code duplication rather than cyclomatic complexity and given that these are almost dictionaries / configurations I don't think that duplication is a cognitive burden.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think that might be fair for this. Mainly because we update the rhd a bit more often than the rhs. So splitting so that we can update the one without breaking the other is a good idea. I would say let's keep this in draft and I will work on that.
The test is failing due to timestamp issue.... That means the test file could be corrupt. Not sure how since this is a test file generated from Intan's simulator. Since it is a binary file I can just read it myself and see if I can figure out what is going on. I think for me what I would say is:
|
Sounds good, let me know if you need to upload something again. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The number of times I've mistyped these test files is outrageous....
This is actually ready for review now. Tests are passing (barring the retest happening right now which should pass). With this PR we now support all formats of Intan (rhd and rhs, traditional + headerless binary formats). If you think it would be beneficial for this release feel free to review now. Otherwise we can wait. @h-mayorquin said he would do another read-over later. So we can either merge sooner and then fix up or wait and tidy more now. I would prefer squashing this one. I had some fights with typos in the paths to the test files, so there are a lot of junk commits. |
Thanks @zm711 This looks good to me! @h-mayorquin if you want to take another look, otherwise we can squash and merge and include this in the release :) |
I took a second look, it looks good to me. |
Thanks @h-mayorquin! |
This will be adding support for
RHX
rhs files with a separate header forrhs
files. We haven't officially update RHS support since RHS 1.0 and we are on 3.x so this may take a bit of work. We will add tests files soon so that we can properly test this.TODOS
Add support for supply and aux channels in RHSTurns out that there isn't any from newest docs!one-file-per-signal
one-file-per-channel
Neuroconv provenance catalystneuro/neuroconv#789