[ENH] BEP042 - extension for electromyography (EMG)

[drammock]

UPDATE: 09/29/2025

Important

The final review of the BEP042 is up (9/29/2025 to 10/10/2025), Please consider voting and providing your feedback: #2219

---

This adds support for Electromyography (EMG) datasets. CIs are not expected to pass yet.

cc @neuromechanist @jwelzel @larsoner @arnodelorme @robertoostenveld feel free to push directly to this branch, I'll add you as repo collaborators on my fork.

We meet regularly to discuss this BEP
Next meeting: 18 Dec 2024 on https://ucsd.zoom.us/j/96433382377
Communication channel on github repo / matrix / slack / discord : #1371

Note

See the HTML version of the proposped specifications at this readthedocs page

closes #1371

[drammock]

cc @agramfort

[sjeung]

Hi, @neuromechanist pointed me to this PR and I would like to share some thoughts. This seems to be pretty advanced in terms of sensor placement description which was not very well defined in the motion BEP :)

• .json EMGPlacementScheme field : could be more restrictive with keywords?
  For instance in case of absence of a common process one MUST write "channel-specific".
  Keywords "visual reference", "palpation", "functional localization" ... can be explicitly recommended rather than having people use different keywords for describing the same thing (e.g., "visual inspection", "pressing on the skin"... ). They may even use multiple of those methods at the same time and in that case they can separate them with some designated delimiter (that can be prescribed too) for easy parsing. This depends of course on how well-categorized these processes are but since you are allowing unprescribed keywords for names of external schemes anyway (like SENIAM) it would be okay to not be comprehensive.

• In the example on the website draft I read "EMGPlacementScheme": "midpoint
  between cubital fossa and radial styloid process", : this seems to contradict the description that says NOT to give the target muscle description

• .json EMGReference : similarly to EMGPlacementScheme field, you may simply have them choose between 1) a specific name, 2) keyword "channel-specific", or 3) "bipolar". Mix of bipolar and other references would then be a case of "channel-specific".

• .json SkinPreparation : might this be channel-specific as well? For instance in EEG we would use the abrasive gel only for EOG and not for other electrodes. Then having this as a column in channels.tsv with description of keywords in channels.json can be helpful

[drammock]

Hi @sjeung, thanks for the feedback / ideas.

• .json EMGPlacementScheme field : could be more restrictive with keywords?

done in e84cadc

In the example on the website draft I read "EMGPlacementScheme": "midpoint between cubital fossa and radial styloid process", : this seems to contradict the description that says NOT to give the target muscle description

Those are skeletal landmarks, not muscles. But we've reworked EMGPlacementScheme to be an enum now, so that example will need to change anyway.

.json EMGReference : similarly to EMGPlacementScheme field, you may simply have them choose between 1) a specific name, 2) keyword "channel-specific", or 3) "bipolar". Mix of bipolar and other references would then be a case of "channel-specific".

This was the intent, perhaps it's just not worded clearly enough? Suggestions for clarification are welcome.

.json SkinPreparation : might this be channel-specific as well?

For EEG, I think abrasive gel isn't used because of possible damage to hair. According to @neuromechanist it would be odd to use a different skin prep for different EMG sites in the same session, so we'll probably leave this as as-is.

[drammock]

I think this BEP is ready for a thorough review by the team: @robertoostenveld @larsoner @neuromechanist @arnodelorme @JuliusWelzel @tjeerdboonstra

cc @agramfort

[arnodelorme]

The document looks comprehensive https://bids-specification--1998.org.readthedocs.build/en/1998/modality-specific-files/electromyography.html. A few comments:

• Sampling Frequency Specification: The sampling frequency is expected to be the same for all electrodes right?

• "EMGPlacementScheme" is set to "midpoint between cubital fossa and radial styloid process" in the example, but the specification says it should be "Measured", "Other", or "ChannelSpecific"

• For channel.tsv, maybe "reference" should be "reference_electrode" to mirror the column "signal_electrode" and make it clearer to users

• EMGCoordinateSystem must be one of "Others" (or maybe the other keywords are missing). This is not accurate since the other coordinate systems seem allowed https://bids-specification--1998.org.readthedocs.build/en/1998/appendices/coordinate-systems.html

[drammock]

• Sampling Frequency Specification: The sampling frequency is expected to be the same for all electrodes right?

In the majority of cases yes. But not necessarily, if there are e.g. some grid devices and some bipolar devices at different spots on the body, recording into separate amplifiers / data files but acquired simultaneously. These would get different values for the acq- entity.

• "EMGPlacementScheme" is set to "midpoint between cubital fossa and radial styloid process" in the example, but the specification says it should be "Measured", "Other", or "ChannelSpecific"

good catch. That should be Other and the text should be in EMGPlacementSchemeDescription --- which is missing from the list of *_emg.json fields.

• For channel.tsv, maybe "reference" should be "reference_electrode" to mirror the column "signal_electrode" and make it clearer to users

I went back and forth on that question. reference already exists as a defined column for EEG datasets, so it was easier / more consistent to re-use it... but I agree that it would be good if the two column names were more parallel. I think @neuromechanist and I agreed that calling the other column just "signal" was too ambiguous, so maybe calling it reference_electrode (and thus breaking the similarity with other modalities) is the best way forward.

• EMGCoordinateSystem must be one of "Others" (or maybe the other keywords are missing). This is not accurate since the other coordinate systems seem allowed https://bids-specification--1998.org.readthedocs.build/en/1998/appendices/coordinate-systems.html

I think this is actually correct as-is. Other coordinate systems are allowed for other modalities, but we're making the assumption that things like CTF, NeuromagElektaMEGIN, CapTrak, etc are not relevant for the vast majority of EMG datasets, and that coordinate systems for EMG datasets will almost always be "custom" (AKA, will define their own origin and XYZ directions, based on anatomical landmarks not on the skull).

[JuliusWelzel]

Hello,

thanks very much for the great progress! I have some remarks listed below:

1. The BIDS definition for the acq-label reads as follows:

"Definition: The acq- entity corresponds to a custom label the user MAY use to distinguish a different set of parameters used for acquiring the same modality."

In EMG BIDS the acq-label is used to differentiate between recording systems, not parameters. While I do understand it is simple to use, maybe BIDS in general could introduce a sys label for filenames for this purpose. For motion data we introduced a new tracksys label for the same use case. Probably should have named that sys :D

Also the acq-label is explained again with the coordinate_system.json. I would move the explanation further up.

2. Provide some more information how the acq_time is to be formated (e.g. similar to MOTION-BIDS):

In the scans.tsv file, date-time information MUST be expressed as indicated in Units, which allows to use sub milisecond presicion.

3. In the description of the sensor locations, are the example structures a MUST? E.g. if landmarks are digitized with a Polhemus ... coordinates of an electrode MUST be given with x,y,z coordinates?

4. The table of Hardware information has a nan row at the 5th position

5. The example *_emg.json is not a valid .json file due to the last comma (after "jumping").

6. For the channel description it is stated: "Channels SHOULD appear in the table in the same order they do in the EMG data file". Are headers a MUST ind the EMG data file? If not how can the channels be matched, if not by order. I would propose to make this a MUST.

7. The restricted keyword list for the channels.json seems a little counterintuative. EMG is, at least to my limited knowledge, not often sampled through the same amplifier as Eye-Tracking. I would exlcude EYEGAZE and PUPIL from this list. Probably include POS channels from motion data, as e.g. Vicon offers EMG integration with optical motion capture.

[drammock]

1. The BIDS definition for the acq-label reads as follows [...]
   In EMG BIDS the acq-label is used to differentiate between recording systems, not parameters. While I do understand it is simple to use, maybe BIDS in general could introduce a sys label for filenames for this purpose.

That is an attractive idea. You are right that we chose acq mostly for convenience. It would also be possible to expand the definition of acq (e.g., "different set of parameters or devices used for acquiring the same modality").

Also the acq-label is explained again with the coordinate_system.json. I would move the explanation further up.

it is explained at the end of the initial "EMG Data" section (just before the "Terminology: electrodes vs channels" subsection). It comes up again when discussing coordsystems, and then again when discussing photos. I couldn't see a good way to avoid talking about it in multiple places. In light of that, do you still think it needs to move / change?

2. Provide some more information how the acq_time is to be formated (e.g. similar to MOTION-BIDS)

Are you specifically asking to add the "sub-millisecond precision" bit? (if so, no objection). If not, can you clarify what you think is lacking here?

3. In the description of the sensor locations, are the example structures a MUST? E.g. if landmarks are digitized with a Polhemus ... coordinates of an electrode MUST be given with x,y,z coordinates?

what is MUST, SHOULD, or MAY is open to discussion. There are also likely some more rules to be added, e.g., to make some optional fields required depending on the values in other fields. Regarding specifically the Polhemus case, I would agree that digitized locations MUST include x,y,z based on my experience using Polhemus for digitizing EEG electrode locations. Is there a case where one would use a Polhemus (or similar spatial digitizer) and not provide coordinates in 3D?

4. The table of Hardware information has a nan row at the 5th position

thanks, fixed. It was asking for AmplifierType, which wasn't defined elsewhere. IIRC we decided that wasn't needed, but I can add it back in if folks disagree.

5. The example *_emg.json is not a valid .json file due to the last comma (after "jumping").

thanks, fixed.

6. For the channel description it is stated: "Channels SHOULD appear in the table in the same order they do in the EMG data file". Are headers a MUST ind the EMG data file? If not how can the channels be matched, if not by order. I would propose to make this a MUST.

EDF/BDF necessarily have channel names in the file (which I think is what you mean by "headers" right?). There are also guidelines on what the format of such channel names should look like (modality-space-identifier, i.e., EEG Cz or MEG 1441 or EMG 002). I suppose it would be conceivable to have an EDF/BDF file where the channel names were non-unique (which IMO would be a degenerate case), but I don't think they can be missing.

7. The restricted keyword list for the channels.json seems a little counterintuative. EMG is, at least to my limited knowledge, not often sampled through the same amplifier as Eye-Tracking. I would exlcude EYEGAZE and PUPIL from this list. Probably include POS channels from motion data, as e.g. Vicon offers EMG integration with optical motion capture.

This was originally copy-pasted from EEG, then pruned. I agree it needs refinement... I had a code comment in there for a while saying as much, until I realized almost nobody was reading the source :) For now I'll remove PUPIL, EYEGAZE, ADC, DAC, and OTHER, and add POS.

[neuromechanist]

Thanks, @JuliusWelzel, very insightful comments,

1. Re acq-<label>, I am in favor of expanding the definition of acquisition mostly to avoid introducing yet another entity to BIDS.
   Also, it might be good to consider recording-<label>, which is defined entity although its definition needs to be expanded:

This entity is commonly applied when continuous recordings have different sampling frequencies or start times. For example, physiological recordings with different sampling frequencies may be distinguished using labels like recording-100Hz and recording-500Hz.

IMHO, acq-<label> is more meaningful as it would indicate separate acquisitions.

2. acq_time in the scans_tsv is quite clear IMO. We briefly discussed accommodating a LATENCY channel, if the data has multiple recordings. Probably, we should add it to the list of reserved channel types?
   Here is the description of the LATENCY channel:

LATENCY | Latency of samples in seconds from recording onset (see acq_time column of the respective *_scans.tsv file). MUST be in form of s[.000000], where s reflects whole seconds, and .000000 reflects OPTIONAL fractional seconds.

And the description of how to use it:

In case a tracking system provides time information with every recorded sample, these times information MAY be stored in form of latencies to recording onset (first sample) in the *_motion.tsv file. If a system has uneven sampling rate behavior, the LATENCY channel can be used to share this information.

6. +1 that the relation between the data and channels should be a MUST, this is also problematic for the relation between channels and electrodes (see the detailed discussion here: [ENH] channels.tsv and electrodes.tsv should have a clear relationship #2041).

[JuliusWelzel]

it is explained at the end of the initial "EMG Data" section (just before the "Terminology: electrodes vs channels" subsection). It comes up again when discussing coordsystems, and then again when discussing photos. I couldn't see a good way to avoid talking about it in multiple places. In light of that, do you still think it needs to move / change?

Good point, I think it can stay as it is. Maybe it is worth adding a detailed explanation for the reasoning in the paper.

Are you specifically asking to add the "sub-millisecond precision" bit? (if so, no objection). If not, can you clarify what you think is lacking here?

Yes, sub-millisecond presicion is imo worth mentioning as EMG usually has a high srate. This time resolution is important for good syncronization with other modalities.

what is MUST, SHOULD, or MAY is open to discussion. There are also likely some more rules to be added, e.g., to make some optional fields required depending on the values in other fields. Regarding specifically the Polhemus case, I would agree that digitized locations MUST include x,y,z based on my experience using Polhemus for digitizing EEG electrode locations. Is there a case where one would use a Polhemus (or similar spatial digitizer) and not provide coordinates in 3D?

I am not aware of any case where it is not provided in x,y,z.

EDF/BDF necessarily have channel names in the file (which I think is what you mean by "headers" right?). There are also guidelines on what the format of such channel names should look like (modality-space-identifier, i.e., EEG Cz or MEG 1441 or EMG 002). I suppose it would be conceivable to have an EDF/BDF file where the channel names were non-unique (which IMO would be a degenerate case), but I don't think they can be missing.

True, sorry. But maybe it can be pointed out, that the names in the 'channels.tsv' MUST match the names in the BDE/EDF file?

[JuliusWelzel]

IMHO, acq-<label> is more meaningful as it would indicate separate acquisitions.

Agreed, maybe a PR can be opened to extend the definition for the acq label as @drammock suggested?

2. acq_time in the scans_tsv is quite clear IMO. We briefly discussed accommodating a LATENCY channel, if the data has multiple recordings. Probably, we should add it to the list of reserved channel types?

Good idea, I would be in favor off adding LATENCY to the channel types. The scans.tsv file will also be replace with a recordings.tsv file in BIDS 2.0.

[neuromechanist]

I made it through once and made suggestions. The overall specifications look great. I look forward to the community comments.

[drammock]

ping @robertoostenveld and @tjeerdboonstra. I think we're about ready to open this up to public comment; do you want a chance to go through it again first?

[drammock]

maybe a PR can be opened to extend the definition for the acq label as @drammock suggested?

done in #2090

[yarikoptic]

sys entity feels analogous (so can replace or be replaced with) to

• device/dev- entity + devices.{tsv,json} #2027

idea. So if to parallel exactly, should get systems.{json,tsv}? But then I would prefer devices.{json.tsv} as better descriptive since systems could be abstract ("coordinate system" etc).

[JuliusWelzel]

sys entity feels analogous (so can replace or be replaced with) to

• device/dev- entity + devices.{tsv,json} #2027

idea. So if to parallel exactly, should get systems.{json,tsv}?

Yes! As far as I understand how devices should be used, this is what we wanted to achieve with the tracksys entity for MOTION-BIDS. In the Paper we define a "tracking-system" as:

We define a tracking system as a group of channels that synchronously sample motion data from one or multiple tracked points. To be grouped as a single tracking system, channels MUST share the core parameters of sampling (namely the sampling rate and the duration) as well as hardware and software properties, resulting in the same number of samples and, if available, a single latency channel associated with the rest of the channels.

This resulted in a REQUIRED tracksys-<label> per motion.tsv file.
I think it is important to specify if users MUST define the sys/acq/dev label or if this is optional. We made it required, even though, the majority of motion datasets records data using only a single device. Should BIDS 2.0 remove the tracksys label for the motion data and streamline with whatever is decided in this and similar BEPs?

But then I would prefer devices.{json.tsv} as better descriptive since systems could be abstract ("coordinate system" etc).

As for the terminology, adopting devices.{json.tsv} is preferable over systems.{json.tsv} to avoid confusion with other abstract concepts like coordinate systems. The term "devices" more accurately reflects the physical equipment used in data acquisition, leading to clearer documentation and understanding.

[drammock]

The term "devices" more accurately reflects the physical equipment used in data acquisition, leading to clearer documentation and understanding.

agreed, dev / device is semantically a better entity name than acq (or sys or recording) for what we're grappling with in EMG.

[klotz-t]

Hi all,

We (a Team of researchers from Imperial College London, Umea University, and University of Stuttgart) ran into this BIDS extension proposal while preparing a dataset collection for an EMG-processing benchmark problem and searching for a standardized data format to share that data. We would be highly interested in using BIDS for that purpose.

Using the documentation and the existing data, we have started to convert some datasets into EMG-BIDS format (for example, see https://doi.org/10.7910/DVN/F9GWIW). Our impression from that journey was mostly positive, and we want to share the few issues we struggled with:

• EMG is often acquired together with additional biomechanical data (e.g., joint torque, joint torque velocity, requested trajectories, ...). Currently, we are treating such time series data as MISC channels and specifying the type of the recorded signal in the description fields. It might be worth thinking whether such channels are frequent enough to associate them with their own channel type keyword.
• If such bio-mechanical data is generated (e.g., from dynamometer devices), should the hardware description be added to the EMG-sidecar file or should it go into a separate file?
• In the documentation, task descriptions are also part of the EMG-sidecar file. EMG is typically used in tasks related to motion, and task descriptions can be kind of extensive (even simple isometric tasks can require specification of several joint ankles). This makes the EMG-sidecar files (i) potentially crowded and (ii) they could contain a lot of redundant information that is shared across all subjects. Is there a better place for detailed task descriptions (e.g., in the dataset sidecar file) that would allow us to keep the EMG sidecar file more compact and focus on the truly EMG-specific properties?
• Besides surface EMG, there is also the option of using invasive EMG (there are needle electrodes, fine wire electrodes, thin film electrodes). Should one use the "Description" field to separate these two modalities? Most metadata should be similar between the two modalities, however, it is really hard (maybe even currently not really possible) to keep track of the electrode positions after the insertion. So the coordinate.tsv file would be hard to use in that case.

[JuliusWelzel]

• EMG is often acquired together with additional biomechanical data (e.g., joint torque, joint torque velocity, requested trajectories, ...).

Hi @klotz-t,

sounds like a great project. For motion data there is a seperate specification and paper. This data would go into a seperate folder. If you record motion data which is not yet defined, you can extend the specification to your need with the MISC channel type as mentioned.

[neuromechanist]

@klotz-t , thanks very much for sharing your thoughts. I am glad that even the draft specifications are somewhat helpful 😊.

It might be worth thinking whether such channels are frequent enough to associate them with their own channel type keyword.

Great problem, some things to consider: Ideally, the aim is to share data as "raw" as possible. If the force, requested trajectory, etc., are being recorded by the same instrument as the EMG (such as experiments using OTB), then appending EMG with these channels is excellent. If not, I'd prefer having them as a physio data (see the spec, I am not sure if it accepts formats other than tsv.gz though). Nevertheless, I think adding FORCE (and possibly TORQUE) channel type would be useful, as several EMG instrument manufacturers have integrated force sensors and inputs in their acquisition systems.

If such bio-mechanical data is generated (e.g., from dynamometer devices), should the hardware description be added to the EMG-sidecar file or should it go into a separate file?

Then, it will conveniently go to physio.json

EMG is typically used in tasks related to motion, and task descriptions can be kind of extensive (even simple isometric tasks can require specification of several joint angles). This makes the EMG-sidecar files (i) potentially crowded and (ii) they could contain a lot of redundant information that is shared across all subjects.

(i) Assuming motion using motion data type (= directory) and modality, EMG using emg data type and modality and Force using physio modality (but still inside emg data type), one TASK will have three JSON files, each describing one source of recording. The holistic view can be pulled in post.
(ii) BIDS has an Inheritance Principle, so if the same setup is used for all subjects, you just need to put the JSON files in the root (e.g. task-isometric_<modality>.json), and it will be inherited across the dataset.

Besides surface EMG, there is also the option of using invasive EMG (there are needle electrodes, fine wire electrodes, and thin film electrodes).

Very interesting, although not common. Since we did not have a representation for iEMG, and the use is not very common, we decided not to address potential specific requirements that iEMG may need. Again, I'd imagine if iEMG is recorded on the same instrument, it will go under the MISC channels, and you need to describe the details in the channels.json. This will also allow you to use electrodes.tsv to indicate the electrode-specific specifications and location.
If they are separate instruments, you might want to use physio.

Thanks again for this interesting use-case example.

[klotz-t]

@neuromechanist, thanks for your detailed response.

Maybe one remark regarding the use of invasive EMG. It is true that this modality is little used in research settings. Yet, clinical EMG is almost exclusively acquired using concentric needle electrodes (whereby so-called spontaneous activity serves as a diagnostic indicator for various neuromuscular disorders). If such data is within the scope of BIDS, it might be worth considering if it already fits into the proposed framework / what modifications would be needed.

[neuromechanist]

@klotz-t,

If such data is within the scope of BIDS, it might be worth considering if it already fits into the proposed framework / what modifications would be needed.

I am in favor of adding that, if there is a community (that is, a person, hopefully yourself) familiar with the iEMG research. To make the case, I suggest the following:

1. List some examples of the data shared with iEMG. I know of a couple, including this recent concurrent EMG/iEMG from Bradford et. al..
2. Try to make an example dataset. Look at [ENH] BEP042 - EMG examples bids-examples#480, you are welcome to make a PR to my repo, and I will merge. (I am in favor of having concurrent EMG datasets, since it is one of the unique features of EMG data as compared to EEG/MEG 😉)
3. Identify what metadata needs to be added to the sidecars to accommodate the data.

I think we are at a stage that we still can accommodate this inclusion. But, it still depends on someone that has the familiarity with the research and required metadata.

[klotz-t]

@neuromechanist

I have some experience in invasive EMG, but for this purpose, I had a chat with a few people who are dealing more frequently with intramuscular EMG. Generally, it seems like intramuscular EMG data can be handled with minor adjustments within the current proposal. Here are some initial thoughts:

• Should there be a unique keyword (e.g., "IEMG") to distinguish intramuscular and surface recordings (keyword "EMG")
• Data format -> 16-bit should be sufficient, a lot of data is stored in .wav format (doctors listen to EMG), and it might be worth considering if that is a permissible file format
• ElectrodeType should be a required field, and the most important electrode types are (i) concentric needles, (ii) monopolar needles, and (iii) fine wires
• The surface area of the electrode (e.g., ElectrodeSurfaceArea) does not seem to be a reported field in the sEMG specification and should be a required field for invasive EMG
• ElectrodeMaterial should be a required field for invasive EMG, and next to the electrode material itself,f one should also report the material of the insulator (e.g., in a concentric needle, there is a sensing electrode at the tip of a needle and the cone of the needle serving as reference electrode. They are separated by an insulator)
• One should report the size of the needle, i.e., diameter x length or gauge (common unit used for canula sizes, e.g., reported as 25G)
• Exact electrode positions are challenging to report. Yet, one should roughly report the insertion position (e.g. X% % between two anatomical reference points), the target muscle (if available, adding information like distal, proximal, ...), the depth of the inserted electrode (recommended/optional), and the insertion angle (recommended/optional)
• In invasive EMG recordings, it is also common that the needle is moved within the same session. The best practice would be to make a separate recording per position. Otherwise, needle motion needs to be annotated in an events file.

I can try to make two examples.

1. Traditional clinical recording with a single-channel concentric needle
2. More advanced research setting using a multi-channel configuration

[neuromechanist]

@klotz-t, sorry for missing this. Most of the metadata you pointed out makes sense to me. However, we might want to consider differentiating the MUST and RECOMMENDED for some of the fields.
Given the scarcity of the iEMG datasets, I am more in favor of having emg as modality, and using a type key in the emg.json to distinguish between sEMG and iEMG. Even if there are concurrent sEMG and iEMG recordings, we can distinguish them with the recording entity.
Please kindly go ahead with the examples you mentioned and add them to bids-standard/bids-examples#480 with the metadata that you see fit, so we can discuss them sooner than later.

Thanks

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 82.71%. Comparing base (b9a6673) to head (187ce78).
⚠️ Report is 7 commits behind head on master.

Additional details and impacted files

@@           Coverage Diff           @@
##           master    #1998   +/-   ##
=======================================
  Coverage   82.71%   82.71%           
=======================================
  Files          20       20           
  Lines        1608     1608           
=======================================
  Hits         1330     1330           
  Misses        278      278           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[drammock]

@effigies re: our conversation earlier about needing to back out earlier changes: I think we want to revert c6d4388 and 8b0393a in this PR, right? IIUC we won't need it; most of what we need will be in the new associations.coordsystems (plural), and we can check for e.g. the presence of keys (ParentCoordinateSystem, AnchorElectrode etc) via src/schema/rules/json/emg.yaml I think.

[effigies]

I think we want to revert c6d4388 and 8b0393a in this PR, right? IIUC we won't need it;

Correct.

[drammock]

@effigies and @neuromechanist I think now it's time to squash all commits here, per review policy? For me locally, all the datasets at neuromechanist/bids-examples#3 pass validation when run against bids-standard/bids-validator#268 and the CIs here are happy too

[agramfort]

I have not had time to dig into lots of details here unfortunately but reading the preview at https://bids-specification--1998.org.readthedocs.build/en/1998/modality-specific-files/electromyography.html you have my +1. It covers the use cases I have top of mind. thanks @drammock @neuromechanist for pushing this and all reviewers who helped bring this proposal to this level 👏

Outdated

[VisLab]

Nice job! Here are some minor comments/suggestions:

1. Consider making _task-<label> optional for EMG data and channels. It is optional for electrodes.tsv. I know you said that task could be conditions rather than behavioral, but it seems non-intuitive and unnecessary. There are experiments for which the notion of "task" is not relevant. We are having a discussion about making it optional for EEG for the same reason.
2. In Electrodes vs. Channels the = signs look very odd. Maybe bold with :, e.g. Electrodes:
3. Do a global search of .tsv and .json -- the use of code typeface is inconsistent. Also sometimes its n/a and sometimes 'n/a'.

[arnodelorme]

+1 on my side as well.

[neuromechanist]

Please review the EMG-BIDS proposal, an initiative aimed at integrating EMG data sharing within the BIDS ecosystem.

Your review will contribute to the development of specifications that strike a balance between thoroughness and clarity and ease-of-use.

To conduct a code review, you can examine the files modified from the tabs above.

Alternatively, you can review the HTML preview of the proposed specifications and/or the examples.

In the end, please provide your comments on #2219, or upvote and approve the proposed specifications.

[neuromechanist]

Important

The final review of the BEP042 is up, Please consider voting and proving your feedback: #2219

@agramfort, @VisLab, @arnodelorme, @larsoner, thanks much for your feedback and review here. Please consider voting on the first post on the Discussion Thread 🙌