On the philosophy that is better to ask forgiveness than permission, I have tentatively gone ahead and done things as I thought best:
- new class ParsedChord defined in chordlist.h/chordlist.cpp to hold the parsed form of the chord - the actual parsing function is a constructor for this class - ChordDescription now contains a list of ParsedChord's - the ParsedChord list for a ChordList (list of predefined chord id's) is populated when the chord description XML file is read - if there are multiple names for a given chord id, there will be multiple ParsedChord's as well, *if* the names actually parse differently - Harmony::parseHarmony in harmony.cpp creates a ParsedChord object for the user-input chord, and if the search for a literal match against the names in the ChordList fails, it looks for a match against the ParsedChord's in the ChordList In the process, I also removed the toLower() performed before the literal comparison, as that was broken (it made "m" match "M", and thus potentially turned minor chords into major or vice versa) and is rendered unnecessary by the parser. All seems stable, and I'm quite happy with how it works. Since this is my first actual coding venture in MuseScore, I feel I should hold off checking this all in and submitting a pull request until I hear some sort of confirmation that I am not seriously off base in how I chose to do things. Marc ------------------------------------------------------------------------------ Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2 _______________________________________________ Mscore-developer mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mscore-developer
