Chord symbol invisible after importing due to style file read failure
Reported version
3.6
Type
Functional
Frequency
Once
Severity
S4 - Minor
Reproducibility
Always
Status
active
Regression
No
Workaround
No
Project
As of MuseScore 3.6.0, importing a MusicXML harmony results in a fretboard, but the associated chord is invisible. The chord is actually imported and shown correctly after saving in MuseScore format and opening again.
Example: see testfile mtest/musicxml/io/testChordDiagrams1. For the chord in measure 2, the debugger shows the chord is present but width/height are 1.00/2.63, which was 26.30/41.39 in 3.5.1.
Relates to #270643: [EPIC] MusicXML import/export issues and #283681: [EPIC] Fretboard diagram issues
Comments
Hmm, I guess https://github.com/musescore/MuseScore/pull/8014 fixes this for master and https://github.com/musescore/MuseScore/pull/7455 for 3.x? Or what am I missing?
Actually those don't deal with the chord symbols. But then again I can't reproduce the issue, not with the sample file from that other issue (attached here now to), not with MuseScore 3.6.2, it does import and show the chord symbol
I wonder if the issue here was simply not running a local build that was never "installed" (eg, "make install" was not run), and thus the chord description files were missing. If so, this can be closed. If not. we'd need more precise steps to reproduce the problem, as the above score imports just fine for me too.
This is on a local build (I have been using local builds only since I started working on MuseScore more than ten years ago). So far I have observed this issue in all commits I tried since 3.6.0. No, "make install" does not solve it for me. Note that I develop on MacOS, the issue may be Mac specific.
Reproducing simply consists of loading the attached file. No further steps required, no none-default settings used.
With that file it does not reproduce for me, not in 3.6.2, nor in a selfbuild 3.x
![Guitar_fretboard_G.png]( "Guitar_fretboard_G.png")
I can't with mtest/musicxml/io/testChordDiagrams1.xml either
![testChordDiagrams1.png]( "testChordDiagrams1.png")
In reply to This is on a local build (I… by Leon Vinken
It's not enough to simply run "make install* - you then have to make sure to actually use the installed copy of the file. At run time, MuseScore uses its own folder location as the starting point to find things like chord description files - and this has been true for as long as I've been involved as well (also about 10 years). So local builds never find chord description files and always fail to show chord symbols unless you actually run from the folder that "make install" installed into.
I suppose it's possible that on macOS, the build process is broken and "make install" no longer copies the necessary files (the XML files in share/style) to the install folder. If you don't see them there in "style" under your install folder, you could try copying them manually.
But as another test - try entering a chord symbol normally (Ctrl+K, type the "G7"). Does it show in that case? if not - or it shows the 7 but not the G, or vice versa - it's definitely a build/install issue.
Hi Marc, you were right: the issue is related to the chord description file and entering Cmd-K (different key bindings on Mac !) followed by "G7" only shows the "7".
Exact cause still to be determined (will investigate), but I did find 3.x does not call ChordList::read() (which I believe to be the function that reads the chord description file) until I explicitly load a new style (menu "Format / Load Style.."). That also results in the chords displaying normally.
Note that the issue does not happen on my locally built 3.5.1 but does happen on 3.6.0 and 3.x. As far as I remember all were built and installed in the same way, although it is conceivable I made an error somewhere. Will update this issue once I have determined what exactly is happening.
There are definitely differences in how styles are handled for 3.6, due to the switching that happens on open to set the proper defaults for 3.6 vs pre-3.6. But the chord list read should happen no matter what, I would think - only question is whether it actually finds one. Maybe be sure to set a breakpoint high enough up that you're catching the attempt to find the chord list, not just the read after opening it. I suspect it's the find that is failing. Although again, why that would be different between 3.5 and 3.6 is still mysterious, as I'm not ware of any changes in that.
Cause found: when importing a file (e.g. in MusicXML format) with the import preferences set to "use style file" instead of "built-in style" and the style file cannot be read, the chord list is also not read. Note that no error is reported (!).
This is not a regression, nor is it related to MusicXML import. In this case the cause was I still had a 3.5.1 style file selected, which is no longer accepted due to the its version. The lack of error handling made this issue non-obvious to understand.
I have attached a debug patch for the current 3.x (commit 7d1c732) which adds some error reporting (console only) and logging that illustrates what happens.
Ah, this makes sense then. Probably we should do some sort of fallback if the style file cannot be read. Or just display an error, so you are aware you have a bad style specification.