One problem/question regarding CFS data

[Gio Batsikadze]

Hi,

Thank you for creating this library and making it available. You really have saved me and my colleagues weeks of time (will certainly be referenced in paper) 

I am working on the EMG data. Long story short : I am recording and analysing single or double-pulse TMS-induced motor evoked potentials, controlled by CED Signal software.  

When I only have one sampling state - the analysis with stfio goes perfectly fine, but with multi-state recording there's a problem: I cannot group frames separately according by the state number (screenshot).  I looked through the library and could not find the corresponding variable. 

I could be missing something very simple, I'd really appreciate your help.

Thanks in advance,

Gio

[Gio Batsikadze]

P.S. attached the file as well

[Christoph Schmidt-Hieber]

@Alois Is this variable supported by libbiosig? If so we could expose
it to the Python interface.

[Gio Batsikadze]

any news about this issue? 

[Christoph Schmidt-Hieber]

Which platform are you using?

> --
>
> ---
> You received this message because you are subscribed to the Google Groups "stimfit" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to stimfit+u...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Christoph Schmidt-Hieber]

Hi Alois,

Thanks for your work on this!

However, I’d strongly advise against adding *any* new menu entries that are only applicable to a single file type - in this case only to a single user! (no offense Gio) The menu is already far too cluttered. If anything, we should reduce the number of entries.

Christoph

> On 6 Mar 2017, at 01:37, Alois Schloegl <schl...@ist.ac.at> wrote:
>
>
> Dear Gio,
>
> here is an experimental version for testing:
>
> https://pub.ist.ac.at/~schloegl/tmp/stimfit-w64-20170303.exe.zip
>
> It contains new menue entries
> Menue->Edit->Select .. traces of type
> Menue->Edit->Unselect .. traces of type
>
> When you then type in the segment type number (typically starting from 1
> upwards), the corresponding segments are (un-)selected. Ideally, this
> should become a pull down menu containing valid selection entries.
>
>
> Alois
>
>
> On 2017-03-04 09:46, Alois Schloegl wrote:
>> Dear Gio,
>>
>>
>> thanks for the reminder. Yes, libbiosig is supporting these events, and
>> they are stored in the event table. I've pushed just just now a patch to
>> stimfit, that supports reading these labels into the SectionDescription
>> field
>>
>> In order to make use of this information, I guess we'll also need some
>> menu/gui entry, that allows the selection of certain traces based on
>> Section/Description field.
>>
>>
>> @Christoph: Could you look at this as well ?
>>
>>
>> Best,
>> Alois

[Gio Batsikadze]

Hi all,

Thank you very much for the responses.

I have checked the experimental version and it has perfectly selected the specific entries, so I can confirm that it works just fine.  

I'm using STFIO on python 2.7.11 (64bit)

Will this also be added to the python module?

Regards,

Gio

[Christoph Schmidt-Hieber]

Hi Gio,

> On 6 Mar 2017, at 15:05, 'Gio Batsikadze' via stimfit <sti...@googlegroups.com> wrote:
>
> Hi all,
>
> Thank you very much for the responses.
> I have checked the experimental version and it has perfectly selected the specific entries, so I can confirm that it works just fine.
> I'm using STFIO on python 2.7.11 (64bit)
> Will this also be added to the python module?
>

Yes. The idea is in fact to make features and metadata that are specific to certain file types and users *only* available through the Python shell instead of adding them to the GUI.

Are you using stfio on Windows?

If you’re using the latest development code, your entries are already accessible via stf.get_recording_comment() or stfio.Recording.comment

Best wishes
Christoph

[Gio Batsikadze]

Yes, windows. sorry forgot to write that. 

I will update my stfio version and will give a feedback as soon as possible. 

[Christoph Schmidt-Hieber]

> On 6 Mar 2017, at 15:15, 'Gio Batsikadze' via stimfit <sti...@googlegroups.com> wrote:
>
> Yes, windows. sorry forgot to write that.
>
> I will update my stfio version and will give a feedback as soon as possible.
>

I’m afraid you’ll have to wait until I’ve found a Windows box to build the latest version of stfio in this case, unless you’re building from source.

Should take me about a week.

>
>
> On Monday, April 18, 2016 at 9:45:27 AM UTC+2, Gio Batsikadze wrote:
> Hi,
>
> Thank you for creating this library and making it available. You really have saved me and my colleagues weeks of time (will certainly be referenced in paper)
>
> I am working on the EMG data. Long story short : I am recording and analysing single or double-pulse TMS-induced motor evoked potentials, controlled by CED Signal software.
>
> When I only have one sampling state - the analysis with stfio goes perfectly fine, but with multi-state recording there's a problem: I cannot group frames separately according by the state number (screenshot). I looked through the library and could not find the corresponding variable.
>
> I could be missing something very simple, I'd really appreciate your help.
>
> Thanks in advance,
>
> Gio
>
>

[Christoph Schmidt-Hieber]

Hi Alois,

Thanks for your input!

If you think that these entries are used across more file types and users, I’m fine with adding a menu entry. You know the common file types far better than I do.

I would still recommend the following:

1) Keep common menu entries that are standard across all GUI software (Edit->Select, Edit->Select all, etc.)
2) Make the new menu entries work across all file types. We could e.g. use an entry like “Filter selection” or similar, and this could include the current menu entry “filter every n-th trace” as well as filtering for the entries that Gio uses.

Gio’s entries should all be present in the comment, but it’s a string, so he’d have to write a parser to get to the information.

On the long run, it would probably make more sense for the comment to be a dictionary so that the values can be accessed more easily.

Free text could still be stored under a key “comment_text” or similar.

Let me know what you think.

Best wishes,
Christoph

> On 7 Mar 2017, at 08:18, Alois Schloegl <alois.s...@ist.ac.at> wrote:

>
> On 2017-03-06 15:12, Christoph Schmidt-Hieber wrote:
>> Hi Gio,
>>
>>> On 6 Mar 2017, at 15:05, 'Gio Batsikadze' via stimfit
>>> <sti...@googlegroups.com> wrote:
>>>
>>> Hi all,
>>>
>>> Thank you very much for the responses. I have checked the
>>> experimental version and it has perfectly selected the specific
>>> entries, so I can confirm that it works just fine. I'm using STFIO
>>> on python 2.7.11 (64bit) Will this also be added to the python
>>> module?
>>>
>>
>> Yes. The idea is in fact to make features and metadata that are
>> specific to certain file types and users *only* available through the
>> Python shell instead of adding them to the GUI.
>>
>> Are you using stfio on Windows?
>>
>> If you’re using the latest development code, your entries are already
>> accessible via stf.get_recording_comment() or
>> stfio.Recording.comment
>
>

> If the content of these are sufficient, the latest changes would not
> have been necessary. Gio, is it correct that these fields would be good
> enough ?

>
>
>>
>> Best wishes Christoph
>>
>>
>>> Regards,
>>>
>>> Gio
>>>
>>>
>>>
>>> On Monday, March 6, 2017 at 8:03:54 AM UTC+1, Christoph
>>> Schmidt-Hieber wrote: Hi Alois,
>>>
>>> Thanks for your work on this!
>>>
>>> However, I’d strongly advise against adding *any* new menu entries
>>> that are only applicable to a single file type
>

> It is not necessarily limited to only one file type. There are other
> file formats that can make use of this (e.g. GDF, EDF+, BDF+, and a
> number of other format that support Annotations, Marker and event
> information).

>
>
>>> - in this case only
>>> to a single user! (no offense Gio) The menu is already far too
>>> cluttered. If anything, we should reduce the number of entries.
>
>

> As far as I understood it, that functionality was not represented in
> Stimfit so far. I could have added this to the other Trace selection
> options, or we can omit these entries. The menue entries are not
> perfect anyway, the better option would be some pull-down menu of a
> selection of marker types included in the actual file. The question for
> me is, whether we
> should go forward with this, or whether we should revert these change.
>
>
> Best,
> Alois