search

lrkrol / SEREEGA

SEREEGA: Simulating Event-Related EEG Activity
64 stars 17 forks source link

Way to get trial-wise simulation parameters #4

Open behinger opened 5 years ago

behinger commented 5 years ago

Hi! Great toolbox, enjoyed it so far :-)

Is there any plans that would allow you to get the signal's parameters per trial, e.g. peaklatency, peakamplitude? As far as I can see this is currently not supported and not trivial to add.

But it would be superhelpful to have ground-truths to evaluate single-trial algorithms.

Thanks again for the toolbox.

lrkrol commented 5 years ago

Thanks for raising a good point -- indeed, this is not currently supported and not trivial, but I can see it would be good to have. Did you have any particular format in mind? It could be something like

Epoch  Component  Signal  Param1  Param2   
    1          1       1   value   value
    1          1       2   value   value
    1          1       3   value   value
    1          2       1   value   value  ...

except that different signals can of course have a different number of parameters...

For now, if this is something you need, a dirty hack could be the following. All deviating parameters are set for each trial using utl_apply_dvslope. You could have this script write to a file or global variable, make sure you know in which order the parameters are written, and then extract them again as needed. (But don't tell anyone I actually suggested this.)

behinger commented 5 years ago

I did not have a format in mind right now, maybe if I dive in more to what I need, I could give more details. Right now this is just something that occured to me but I might not proceed with.

best of course would be if one can specify their own table to generate their own data, that is, separate the parameter generation and the signal generation.

The hack would definitely work for my projct right now :-)

lrkrol commented 5 years ago

A custom table would indeed be best, but would require a somewhat radical re-structuring of pretty much everything. I'll keep it in mind...

And I have to correct myself: utl_apply_dvslope is used for all deviations and slopes, but not for shifts, which were added relatively recently and are used by some ERP and ERSP parameters (peakLatency and frequency, respectively). If you're using shifts, the above-mentioned hack unfortunately doesn't work. I could consolidate it all into a utl_apply_dvslopeshift function, which would allow the hack to work again, and is probably better practice anyway.

Are you using shifts? If so, I could prioritise this utl_apply_dvslopeshift thing.

behinger commented 5 years ago

for my application I don't think right now the shifts wouldn't be super important, I guess I could do two hacks ;). So don't put any priority on it :-)

lrkrol commented 5 years ago

Intermediate update: the master branch now has the utl_apply_dvslopeshift function, which consolidates all deviations, slopes, and shifts into a single file for your one-stop hacking pleasure.

Outputting a table is still on the list somewhere.