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

[Documentation]: Add probe setting tutorial #635

Open
2 tasks done
CodyCBakerPhD opened this issue Nov 9, 2023 · 3 comments
Open
2 tasks done

[Documentation]: Add probe setting tutorial #635

CodyCBakerPhD opened this issue Nov 9, 2023 · 3 comments

Comments

@CodyCBakerPhD
Copy link
Member

What would you like changed or added to the documentation and why?

From #634

Add a thorough doctested tutorial showing how to set probe examples on one of the test files

Note: remember that it needs in_place=True and group_mode='by_shank' to produce expected RecordingExtractor structure

Do you have any interest in helping write or edit the documentation?

Yes.

Code of Conduct

@magland
Copy link
Contributor

magland commented Nov 9, 2023

Note: by_shank only applies to the case where the probe has a shank_id property (e.g., if it was created from a dataframe with a shank_id column)

@bendichter
Copy link
Contributor

@CodyCBakerPhD What if we allowed for probe_interface_file_path as an optional arg of e.g. IntanRecordingInterface? This would make it user-friendly and would move us towards supporting this feature in the yaml spec and in the NWB GUIDE.

@CodyCBakerPhD
Copy link
Member Author

There is nothing specific in this issue about the IntanRecordingInterface; I think we'd want a more general solution that can apply to any RecordingInterface

I've seen users make and set their probes entirely in-memory (no external files) - or loaded from something in the existence probeinterface library - so we need to be able to support both the current programmatic setting interaction, and yes a convenience function such as set_probe_from_file (point it to a tabular file; .csv, .tsv, .xlsx, etc. of the expected structure) would also help

The GUIDE can and will implement something about this but it has as much freedom as the API does, so no matter what approach we use it can inherit it. Actually, for the GUIDE, having it NOT be in source data would be more intuitive since one possibility is to embed the users probe table directly via the metadata page

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

No branches or pull requests

3 participants