MusicXML 3.1 gives many elements an optional id attribute. mx::api exposes the id of elements that have a matching mx::api type (#399). <harmony> and <frame> were left out.
Today the value is dropped. Reading a file loses it, and there is no way to author one.
DirectionData::chords is a std::vector<ChordData>. One ChordData models one <harmony-chord>, not one <harmony>. DirectionWriter::createHarmonyElements writes all of a DirectionData's chords into a single <harmony> element. Several ChordData can therefore share one <harmony>, and none of them owns its id.
<frame> is a child of <harmony>, not of a <harmony-chord>. mx::api holds it as ChordData::frameData (src/include/mx/api/ChordData.h), so it has the same problem.
MusicXML 3.1 gives many elements an optional
idattribute.mx::apiexposes theidof elements that have a matchingmx::apitype (#399).<harmony>and<frame>were left out.Today the value is dropped. Reading a file loses it, and there is no way to author one.
DirectionData::chordsis astd::vector<ChordData>. OneChordDatamodels one<harmony-chord>, not one<harmony>.DirectionWriter::createHarmonyElementswrites all of aDirectionData's chords into a single<harmony>element. SeveralChordDatacan therefore share one<harmony>, and none of them owns itsid.<frame>is a child of<harmony>, not of a<harmony-chord>.mx::apiholds it asChordData::frameData(src/include/mx/api/ChordData.h), so it has the same problem.