search

mne-tools / fiff-constants

Bookkeeping and documentation of FIFF file format constants
4 stars 12 forks source link

ENH: Add channel block information #33

Closed larsoner closed 3 years ago

larsoner commented 3 years ago

Better solution for channel names > 15 chars.

mkajola commented 3 years ago

This is general one on the development. Is the current branching scheme enough, if we start to develop the spec further here in Github. That would mean that there will be "experimental" specs, and I would expect that head of the master is "valid". Different approaches are possible, also this one. Another is question about github - is there comment/discussion area with "branch-scope"? Or is that in pull requests only.

mkajola commented 3 years ago

Hello Eric, been bit busy.. I am still not fully home with github, so please excuse me about plenty of questions. I think you are right that for this purpose the current scheme is fine. One can use the (git) tags when one wants to have a "stable" release.

And for the (fiff) tags, they look fine too. One small thing. I think that the data type of ch_coord_frame is enum(coord), and ch_coil_type is enum(coil), so that are bound to a specific value set and enums are ints anyway. The description should be 'application agnostic', so referring coildef.dat is not quite optimal. I suppose we can keep the coil for now, though nowadays sensor might be more descriptive. We can add aliases later if we wish. So, almost there. What would be a good place for rules - like that there must be at least ch_scan_no in the block, and that the block overrides the structure. That does not really fit well in the dictionary, so maybe I just must write these in the manual.

larsoner commented 3 years ago

I think that the data type of ch_coord_frame is enum(coord), and ch_coil_type is enum(coil)

Done!

What would be a good place for rules - like that there must be at least ch_scan_no in the block, and that the block overrides the structure. That does not really fit well in the dictionary, so maybe I just must write these in the manual.

Yeah these seem like manual-level entries probably. I don't see a good way to put these in the .txt files currently.

If you and @jnenonen are happy with this version, feel free to click the big green button! I usually do a "Squash and merge" because it puts all the changes into a single commit automatically, which keeps repository size small and makes git bisect work nicely.

mkajola commented 3 years ago

Ok, done.