[MusicXML import] [3.6.0 regression] fretboard incorrectly imported

• Jan 28, 2021 - 07:17
Reported version
3.6
Type
Functional
Frequency
Once
Severity
S4 - Minor
Reproducibility
Always
Status
PR created
Regression
Yes
Workaround
No
Project

Attached MusicXML file imports correctly up to 3.5.1, but in 3.6.0:
- the "G" is missing
- several strings are incorrectly shown as unplayed

Relates to #270643: [EPIC] MusicXML import/export issues and #283681: [EPIC] Fretboard diagram issues


Comments

No comment about missing "G" text here, but upon examing 3.x's current code, it looks as though the cause for the excessive "X" markings is caused by the following function:

void FretDiagram::init(StringData* stringData, Chord* chord)
line 268-9:
for (int string = 0; string < _strings; ++string)
....setMarker(string, FretMarkerType::CROSS);

FretMarkerType:: can also be NONE, which intuitively makes sense to have as the initialization. I'm not sure what the repercussions would be by making NONE be the init, as I don't at the very moment have a local build, but again intuitively that shouldn't cause any problems: that is what seems is in need of testing. Having FretMarkerType::CROSS be the default is relying upon the following setDot method calls to clear the crosses when now it no longer does so in order to facilitate multiple dots in addition to possible crosses for users who want fretboard diagrams not necessarily as chord charts but rather fret charts (scales/patterns/etc).

Update: a problem here is that musicxml export doesn't have any "X" data. For example: if you make a fretboard diagram as being for a 6 stringed instrument having a dot on the second fret for the 4th string, and have two "X's" on the 6th and 5th string like: [XX2---] where the first three strings have no data at all..., after exporting and reading the musicxml file, i see no explicit "x"s set anywhere but only the fret "2" marking!

Question becomes: is there a way to explicitly get "x" markings in musicxml? I would imagine, but I haven't researched this. If so, that also needs to be implemented because it doesn't seem to be currently involved in the musicxml writing process. Hope this helps.

Aside issue:
Another situation found while checking this is that the "frets" attribute is not being honored. For example, if the user makes a fretboard diagram only showing two frets, upon export/import, six frets are shown! After checking the corresponding MusicXML file, it looks as though the attribute ["frame-frets"] is written correctly with the appropriate data, so it seems to be having to do with reading/applying rather than exporting.

In reply to by Leon Vinken

Thanks for the documentation link. Based on that, it would seem impossible to follow the musicxml-spec and have the export/import be exactly as how the user defines a fretboard chart if the user doesn't explicitly place mutes on any string with no fret marks (All blank strings will result as having an 'x' upon export/import). Wonder if there's a way around that, or if that is more to be considered as the most appropriate behavior.

And again, switching to NONE instead of initializing to CROSS (mute) still seems appropriate so that an ["X" + a fret mark] don't occur simultaneously on the same string, since apparently OPEN is represented in the xml as a 0 fret and shouldn't cause any problems for fret charts importing/exporting.

Update: Actually, from the spec: The [frame type's unplayed] attribute indicates what to display above a string that has no associated frame-note element. Typical values are x and the empty string.. ... Sounds like that should be capable of being implemented to be used with 'x' depending on the MuseScore data so that [export/import musicxml] could have an explicit reference to 'x' and not implicitly place them when the user never explicitly used them upon import.

P.S.: I get appropriate chord names upon export/import, so for example the missing 'G' mentioned in the first post wasn't a problem on my system. But again, the non-honoring of the amount of frets displayed is slightly off-putting, especially since the actual data is stored in the exported xml file so shouldn't be a problem to get actualized.

P.P.S. The cause of the #-of-frets not working I think is due to setting _maxFrets instead of _frets for FretboardDiagram. Honestly, don't know what _maxFrets is for if _frets is the attribute showing however many frets in the diagram.

Another observation: exporting/importing guitar charts that have multiple dots doesn't seem to work at all when there is an open marker: the data doesn't get saved upon exporting musicxml as verified by reading the uncompressed musicxml file. If there are no markers, however, it appears okay.

I was going to attempt to fix all this coming in from the outset, and the code seemed reasonable to fix by changing how FretDiagram initializes and is read through its methods, but those don't seem to be where the code is occurring having to do with the issue as far I can tell upon first attempt. Hope it gets worked out.

A quick comment about the missing "G": The correlated chord-text isn't attached to the fret-diagram upon importing but rather to the corresponding ChordRest (or maybe just the segment) upon importing.

@Leon Vinken, do you happen to know where in the code the musicxml formation (writing/reading) for fretboard charts are executed? It was said in the dev-chat that you were probably the one who did the work related to it. It doesn't seem to be performed in the normal musicxml functions inside the fretboard diagram class after checking some debug output.

Reading is done by function MusicXMLParserPass2::frame() (for 3.x in importexport/musicxml/importmxmlpass2.cpp).
Writing by FretDiagram::writeMusicXML() (in libmscore/fret.cpp).
It seems FretDiagram::readMusicXML does not exist.

In reply to by Leon Vinken

Thanks for your response.

Weird, I can't seem to verify that FretDiagram::writeMusicXML() is being utilized when exporting to MusicXML. I put a qDebug() statement on its first line and it doesn't appear to output when exporting to MusicXML, nor does some code alteration affect the exported file when viewing it in a text file. Slightly perplexing.

I had code to fix this, but it didn't seem to work as I understood the functions presented as related to the above problem and I'll probably let it go for now. Logically speaking, this is very easy to fix (cancel the mutes when applying anything on first pass placing any element on a string upon import but make sure to use the 'add' flag for adding instead of replacing so that multiple dots work when 0 frets are present.

An example of discrepancy also (multiple dots:

MS3.6:
mscore-diagram.png

Imported MusicXML after export:
xmldiagram.png

the uncompressed music xml shows that those dots are not present (weren't written upon export) rather than incorrectly imported.

Update: after rebasing I notice that the writeXML function is indeed going through the appropriate area now. I'll probably get a PR for this sometime soon (before 3.6.3 since 3.6.2 was released today)

Status active PR created

https://github.com/musescore/MuseScore/pull/7455

1) Fixed extraneous mutes upon import
2) Allow for Open Marking + Fret diagrams upon import
3) Couldn't figure out how to stop some internal "style default" from overwriting the "Frets" attribute of the diagram. Again, the MusicXML is read/written correctly and forms the appropriate diagram with correct _frets attribute and appends to a segment, but afterwards somewhere somehow it's being reset to a stylistic default of "5". Any pointers about that would be cool.