My chord parser is almost done and is working nicely - just a few oddball special cases to add support for. But I have only limited grasp of the overall class structure of MuseScore, so I have questions on how to best integrate my code.
As I've described, I'm hooking in to the loop at the end of Harmony::parseHarmony in harmony.cpp. Previously, the loop took the user-input chordname and tried to find an exact string match for this in the name fields of the predefined list of chord ids (from the chord description files). What I have done is add code to also compare parsed forms of the chords if the literal compare fails, and if I find a match, I note this to fall back on. If the original attempt to find an exact match fails, I settle for a parsed match if one is found. My actual parser is currently a single function, taking a chordname (SQstring) as input and returning a parsed form that is (for now, at least) just another QString. So for instance, given "maj9(#5,#11)" or any conceivable variation on this, my function returns "<major><9><#11><#5>". It would be straightforward to adapt this to produce some other form of output. Not having anywhere better for now to put my parsing function, it's currently just a static function local to harmony.cpp. Also, not having any place for now to store the parsed forms of the predefined chord id names for posterity, I just parse them anew each time I need to perform a comparison. So, my questions are, where would be the best place to put the parsing function, and where would be the best place to store the parsed forms of the predefined chord ids so I am not parsing them anew over and over? Regarding the latter, my feeling is that I should add a member to ChordDescription to store the parsed form for each of the predefined chord ids. I suppose these could be populated when the chord description files are first loaded, but I don't mind populating them as I go. Actually, I'll probably store a *list* of parsed forms - once for each name associated with that ChordDescription. That's because a single ChordDescription can have multiple names, and they might not actually parse the same depending on how they were defined. I also have a sense it might be better long term to define a new class for the parsed form rather than just using a QString. This would give us a place to put methods for rendering directly from the parsed form, for converting to MusicXML or to other forms, etc. But I don't feel I have a solid enough big picture feeling for the code to make a good call as to how that should look. Any class I defined now would probably need to be redefined whenever we got around to actually using it. So I would propose putting that off until if/when we need it, and just keep using a QString for now. Now, if I did define a class for the parsed form, then that would give me a place to put my parsing function, I guess - it would be a constructor. But if I don't define a new class for the parsed form, the question is, where should my parsing function go? It should be available to be called for any input string regardless of whether that string is currently associated with an object or not. Which I guess means it should be a static method of some chord-related class. Easiest would be to put it in Harmony, but I don't know if there is something more "universal" that would make sense. Or maybe this is enough incentive for me to define a new class for the parsed form and make my parsing function a constructor for it. Marc -- View this message in context: http://dev-list.musescore.org/integrating-the-chord-parser-into-the-class-structure-tp7578067.html Sent from the MuseScore Developer mailing list archive at Nabble.com. ------------------------------------------------------------------------------ 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
