search

buzsakilab / buzcode

Code for internal lab sharing - polishing has started but is by no means complete
http://www.buzsakilab.com/
GNU General Public License v3.0
119 stars 128 forks source link

bz_LoadPhy #224

Closed AntonioFR8 closed 6 years ago

AntonioFR8 commented 6 years ago

To load the output of phy into a buzcode sruct. From Manu

brendonw1 commented 6 years ago

Great great. I did want to ask about some of the details/IO stuff: is this a bit redundant with bz_GetSpikes? Are we fine with it as is? Just asking the community.

Maybe an idea is to give it a name like bz_PhyToSpikes and also take away the part where it checks for previous versions of spikes.cellInfo.mat. The reason being that people may come to rely on this while others rely on bz_getspikes and we start to inadvertently diverge the two bits of code. So if you limit this then maybe it's better?

Or integrate this into getspikes... like if no .spk/res/fet/clu then do this code? (or reverse)?

dlevenstein commented 6 years ago

My Two Cents: I think this should be integrated into bz_GetSpikes. That way we don't end up with different load functions we have to maintain consistency throughout. GetSpikes should check which type of data is in basePath, and load the appropriate files through the same pathway. If there are multiple data formats, can ask the user to select.

DavidTingley commented 6 years ago

Agreed with @dlevenstein

dlevenstein commented 6 years ago

That being said, we should probably merge the pull request and add an issue to merge the two functions?

I'll be loading some of Manu's data sorted in Phy this week, I can incorporate into getspikes then

DavidTingley commented 6 years ago

I'd vote to do the merge first, so people don't get used to using it separately?

brendonw1 commented 6 years ago

I agree with this.

DavidTingley commented 6 years ago

merging for now, will eventually be put into bz_GetSpikes instead of being a standalone function