Generate manipulations struct from analogin channel

[samamckenzie]

I propose a function with the following capabilities

1. With the help of an XML in the same basepath, read in data from a flat binary file (basename.dat or basename_analogin.dat or basename_digitalin.dat) with chosen channel(s)
2. there will be two modes of running the script, A) look for pulses with user defined thresholds or a % median threshold defined from the first chunk of the recording session. This will read the entire file in chunks and only detect pulses. B) rely on the existence of an event file basename.evt.sti which defines the start and stop of either pulses (pulse_on/pulse_off) or sines (sine_on/sine_off). Then a slightly different algorithm will be used for pulse detection and sine detection (where onset will be first crossing above some noise threshold around some peak threshold).
3. buzcode manipulation files will be saved with stim onset, offset, type, amplitude, raw channel origin, and description which will need to be inputted manually. data will be saved in a cell array Nx1 where N = # of channels with control signals
4. FMA event files will also be generated for neuroscope compatability.

QUESTION: if you want to make this an automated batch script and populate the decription field which is fixed across experiments, there should be some way to do this (same for animal metadata) what do you propose?

[dlevenstein]

This all sounds good to me. Can option B use either an evt.sti file or an events.mat file? Where is this file generated? If it's just the output of collecting the data then an events.mat file isn't needed, as the info will be in the manipulation file.

[AntonioFR8]

Check the functions bz_getAnalogPulses and bz_getDigitalIn to start

…

On Oct 29, 2019, at 12:09 PM, Dan Levenstein ***@***.***> wrote: This all sounds good to me. Can option B use either an evt.sti file or an events.mat file? Where is this file generated? If it's just the output of collecting the data then an events.mat file isn't needed, as the info will be in the manipulation file. — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub <#355?email_source=notifications&email_token=ADHSQQ2R3DYFYJIWZNEIUPLQRBN4VA5CNFSM4JGLNWIKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOECRDKRI#issuecomment-547501381>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADHSQQZM7Z67Y7B4V3Q56BTQRBN4VANCNFSM4JGLNWIA>.

[samamckenzie]

the issue is that you don't always know a priori when the different stimulations happen, you need to inspect you file and mark those moments (in neuroscope). You could make a matlab GUI and do the inspection like that, but we already have a fast working tool (neuroscope). Therefore I can make the tools for reading in some events.mat file but I will not make any script to generate such a file.

[samamckenzie]

@AntonioFR8 I have those scripts. they only work properly for one stim type (pulses) and they don't work if you maintain a non-zero bias voltage for a subset of the recording. for sines/Gaussians you will overestimate the timing of the start of the stimulus and underestimate its end

[dlevenstein]

Just to make sure I'm following - the .evt. file comes from manual tagging in neuroscope?

No need to make a Matlab GUI that will probably be inferior to neuroscope anyway.

[samamckenzie]

@dlevenstein exactly

[dlevenstein]

when this file is done, will it serve all the purposes of bz_getAnalogPulses and bz_getDigitalIn? If so, those functions should be removed. Is it possible/easier to just modify one of those files and merge them together?

[samamckenzie]

it will call bz_getAnalogPulses under Mode A. and likely bz_getDigitalin if the user asks for this file type (there is only one stim type, and there is no offset). So I think this is a higher level script that should be used to standardize how we make a manipulations struct given input arriving from a variety of sources.

[samamckenzie]

one more note I am standardizing this output to mate with @petersenpeter 's cellexplorer, so his manipulation struct, which used the bare bones buzcode standard as its base, will now be our standard

[dlevenstein]

awesome. Can you make sure to document everything in the wiki