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

Specifying different EEG sampling rate #271

Open brendonw1 opened 5 years ago

brendonw1 commented 5 years ago

This seems pretty hard to do and we might use 1000Hz here at least some times. OK if I put a new module in SessionInfo for LFP sample rate editing? This can then be inherited down the line by things like bz_LFPfromDat etc.

Will people be annoyed if I try this?

dlevenstein commented 5 years ago

This already exists in sessionInfo as sessionInfo.lfpSampleRate

It can be set a few ways 1) set in the .xml file 2) set by an optional input to bz_LFPfromDat, 'outFs' 3) set to default as 1250

Importantly, it's written into the sessionInfo file when the .lfp file is created, so that sessionInfo.lfpSampleRate always corresponds to the sampling rate of the .lfp file

brendonw1 commented 5 years ago

Sorry I do know that. I mean can I make a module in the GUI?

On Wed, Dec 19, 2018 at 11:52 AM Dan Levenstein notifications@github.com wrote:

This already exists in sessionInfo as sessionInfo.lfpSampleRate

It can be set a few ways

  1. set in the .xml file
  2. set by an optional input to bz_LFPfromDat, 'outFs'
  3. set to default as 1250

Importantly, it's written into the sessionInfo file when the .lfp file is created, so that sessionInfo.lfpSampleRate always corresponds to the sampling rate of the .lfp file

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/buzsakilab/buzcode/issues/271#issuecomment-448665999, or mute the thread https://github.com/notifications/unsubscribe-auth/ADXrTX6dpvU_CbpDTzR04hmLPWdoPgZEks5u6m7YgaJpZM4ZaZHH .

dlevenstein commented 5 years ago

Hm. Why would you want to change this after the .lfp file has been created? In my mind the idea is that this gets written when you make the .lfp file and then it stays fixed in sessionInfo (so sessionInfo always corresponds to samplingRate used to make the .lfp)

dlevenstein commented 5 years ago

(that being said, of course you can add the ability to edit sessionInfo - any improvements to the editGUI are welcome, just a little wary of being able to change this once the .lfp file has been created)

brendonw1 commented 5 years ago

I don't change it AFTER the lfp, I set session info before the LFP and then LFPfromDat reads what I specify! I do sessionInfo after my dat and before lfp/spike sorting. I think it makes a lot of sense. This means it serves as a way to TELL buzcode how much to downsample.

I'll make the modification B

On Wed, Dec 19, 2018 at 2:24 PM Dan Levenstein notifications@github.com wrote:

(that being said, of course you can add the ability to edit sessionInfo - any improvements to the editGUI are welcome, just a little wary of being able to change this once the .lfp file has been created)

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/buzsakilab/buzcode/issues/271#issuecomment-448714589, or mute the thread https://github.com/notifications/unsubscribe-auth/ADXrTccmstQseRmgpbobQs3FMB2g1D4Bks5u6pKJgaJpZM4ZaZHH .

dlevenstein commented 5 years ago

If you use bz_LFPfromDat(...., 'outFs', desiredFs) it will do just that - it updates the current sessionInfo to reflect the new desiredFs.

dlevenstein commented 5 years ago

I.e. the way to tell buzcode how much to downsample is by calling bz_LFPfromDat with the specified .lfp sampling rate

brendonw1 commented 5 years ago

Yes but this way the manual part is only once. I set sessionInfo and walk away. I can automate

On Wed, Dec 19, 2018 at 4:24 PM Dan Levenstein notifications@github.com wrote:

If you use bz_LFPfromDat(...., 'outFs', desiredFs) it will do just that - it updates the current sessionInfo to reflect the new desiredFs.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/buzsakilab/buzcode/issues/271#issuecomment-448748847, or mute the thread https://github.com/notifications/unsubscribe-auth/ADXrTT8cpK-s0B04zrXtJ9iULNWmPV8Iks5u6q6BgaJpZM4ZaZHH .

dlevenstein commented 5 years ago

Can't you just automate your call to bz_LFPfromDat?

Anyway, you can of course do what you want. This just wouldn't be my recommended workflow as it allows the user to update/set a parameter that in my mind should only be modifiable by bz_LFPfromDat itself (i.e. to avoid resetting). IMO sessionInfo.lfpSampleRate should only be allowed to reflect the sampling rate that was used, and not be mixed up with the way to tell the function what to use. It just seems like a dangerous functionality to add to me.

brendonw1 commented 5 years ago

I think it’s important that a human being is involved in reviewing the raw data at least once. So sessioninfo up front right after recording is a good place to do that. You set bad channels, regions, lfp. Of course you can automate the call to sessionInfo to pre-specify the default lfp in your larger preprocessing script but I like having a single stage for humans to force people and that’s it. But yeah maybe I can automate the lfp specification. I’ll work on a good workflow. Thanks.

On Wed, Dec 19, 2018 at 4:31 PM Dan Levenstein notifications@github.com wrote:

Can't you just automate your call to bz_LFPfromDat?

Anyway, you can of course do what you want. This just wouldn't be my recommended workflow as it allows the user to update/set a parameter that in my mind should only be modifiable by bz_LFPfromDat itself (i.e. to avoid resetting). IMO sessionInfo.lfpSampleRate should only be allowed to reflect the sampling rate that was used, and not be mixed up with the way to tell the function what to use. It just seems like a dangerous functionality to add to me.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/buzsakilab/buzcode/issues/271#issuecomment-448750816, or mute the thread https://github.com/notifications/unsubscribe-auth/ADXrTTHroTgSCeBXPCnfx6acyORGfn8Mks5u6rArgaJpZM4ZaZHH .

brendonw1 commented 5 years ago

One thing I didn’t mention is that sessionInfo is auto populated from the xml but there’s no good way to specify the lfp from neuroscope when making the xml.

Probably the best thing is to ask lfp freq an input to bz_GetSessionInfo but as a failsafe or for non-automated users it also makes sense to have it as an option in the sessionInfo GUI - so there is some way of specifying it manually - again for people who work that way and given there isn’t another way.

On Wed, Dec 19, 2018 at 5:23 PM Brendon Watson brendon.watson@gmail.com wrote:

I think it’s important that a human being is involved in reviewing the raw data at least once. So sessioninfo up front right after recording is a good place to do that. You set bad channels, regions, lfp. Of course you can automate the call to sessionInfo to pre-specify the default lfp in your larger preprocessing script but I like having a single stage for humans to force people and that’s it. But yeah maybe I can automate the lfp specification. I’ll work on a good workflow. Thanks.

On Wed, Dec 19, 2018 at 4:31 PM Dan Levenstein notifications@github.com wrote:

Can't you just automate your call to bz_LFPfromDat?

Anyway, you can of course do what you want. This just wouldn't be my recommended workflow as it allows the user to update/set a parameter that in my mind should only be modifiable by bz_LFPfromDat itself (i.e. to avoid resetting). IMO sessionInfo.lfpSampleRate should only be allowed to reflect the sampling rate that was used, and not be mixed up with the way to tell the function what to use. It just seems like a dangerous functionality to add to me.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/buzsakilab/buzcode/issues/271#issuecomment-448750816, or mute the thread https://github.com/notifications/unsubscribe-auth/ADXrTTHroTgSCeBXPCnfx6acyORGfn8Mks5u6rArgaJpZM4ZaZHH .

dlevenstein commented 4 years ago

Is this fixed?