Add option to generate xml:ids for each element (note)

[WolfgangDrescher]

When importing MusicXML files in verovio it will convert the score to MEI and randomly generated xml:id attributes will be added to all elements (such as measures, staves, layers, notes, rests, etc.). It would be useful to have an option in MuseScore to add xml:id attributes manually for each element so the IDs can be used in MEI as well. Maybe an option to automatically generate random xml:id for all elements could be useful as well. Once an element has a xml:id assigned it should keep the id when the note is modified.

Have a look at the ongoing discussion on rism-digital/verovio#3301

[shoogle]

Element IDs can be very handy, but they cause problems when comparing files using text-based diff utilities. We actually had element IDs in MuseScore in the past (only for spanner elements like slurs and hairpins, etc.) but we got rid of them for this very reason.

I can't say that performing a text diff is a particularly important use-case for us, so it's possible that we will see element IDs in MuseScore again someday, but we would look for other solutions first.

If IDs are necessary in MEI then I could imagine a compromise solution where we avoid having IDs in MuseScore until the score is exported for the first time, at which point there could be the option to generate IDs and potentially have them preserved in the MuseScore file to ensure the same IDs are used again on the next export. Also, if a score was imported with IDs then those existing IDs could be preserved.

---

To illustrate the problem with IDs and diffs, imagine you and I create separate transcriptions of Beethoven's Für Elise, and now we want to compare our transcriptions to see if there are any differences.

• If the files contain random IDs then any semantic differences between the files will be obscured by the huge false diff created by all the changed IDs.

• If the IDs are systematic based on the time or order in which elements were added to the score, then the IDs will be different unless we both added the same elements at the exact same time or in the exact same order, which is highly unlikely.

• If the IDs are systematic based on the location of elements in the score (e.g. staff number, measure number, beat position, etc.) then the IDs will be the same in both files unless one of us accidentally added/skipped a measure in our transcription, in which case all IDs after that point will be different, which would be problematic if this occurs early in the file.

Of course we could simply filter out the IDs before we do the comparison. But let's imagine the two files are actually the same file stored on different branches of a Git repository (or in different commits on the same branch) and we need to compare them using Git's built-in diff tool (or perhaps the online GitHub viewer). In this case we wouldn't have the option to strip IDs before we do the comparison.

[RhinoHaggis]

Forgive me for utter naïveté here, but isn't a text comparison of the underlying files a really bad way to compare the musical content represented? If this were a feature of Musescore being used, and we needed to verify -say- that two files contained the same notes and rests, in the same mensural layout (durations and positions in time all the same)..... you wouldn't rely on text-comparing the two files and then just taking a guess based on the number of differences.... wwwwwouuuuld you? If I was editing a score for someone I'd certainly want to know if a feature like this didn't actually make the stated comparison, so I could avoid it.

[shoogle]

Text comparison of the raw file contents isn't great for sheet music, but it's the only 100% reliable method.

For example, MuseScore 3 has View > Score Comparison Tool, which is able to produce an "intelligent" diff of two scores, or older versions of the same score.

The intelligent diff says things like "Measure 2: inserted element hairpin", but it doesn't tell you the exact beats the hairpin starts and ends on, which voice it is in, or whether there have been any engraving changes (e.g. nudged up or down slightly). It could tell you those things, but we never got around to implementing it.

That's the problem with an intelligent method: it's based on heuristics and it's up to the developers to handle every possible edge case, whereas a raw text comparison is guaranteed to show all the changes (even ones you don't care about, like IDs).

---

It would be great if we had a visual diff that showed deleted elements in red and added elements in green right in the score view, like suggested changes in Google Docs. However, this is just an intelligent diff by another name. It suffers from the same problems of edge cases and heuristics. The raw textual diff is still more reliable.

It would be great to have intelligent and visual diffs in MuseScore 4, and we probably will one day, but there would still be a place for raw textual diffs, even if it's just there to verify that the intelligent diff hasn't missed anything.

---

This discussion is a bit outdated though, because these days MuseScore (Studio) 4 does indeed save element IDs in MSCX and MSCZ files. Also, it preserves MEI's xml:id within a session, and there is an ongoing effort to preserve (some of) them beyond a session.

MuseScore's IDs are preserved on saving and loading an MSCZ or MSCX file, so you can perform a raw textual diff against older versions of the same score without issue.

However, IDs for new elements are generated sequentially in the order in which elements are created, so if you want to perform a raw textual diff of two scores that were created or edited independently, it's best to strip out the IDs first, but keep a copy of the original files (with IDs intact) so that you can still open them in MuseScore.

[RhinoHaggis]

Ok this makes more sense thank you for your thoughtful reply. This is something I have been wondering about for a long time, and I’ve got to buckle down and familiarize myself with the code base so I’m not just talking outta my butt in vague abstractions… but on the user end it seems like the improved hairpin behavior (4.4) is the tip of the iceberg for relating things in a way where the musical content could be “understood”, e.g. musical time-values and logical relationships between more objects distinguished from their layout-position-by-a system-of-offsets.