WYTIWYG chord symbols #382
Conversation
A chord description object is now generated for each (unique) unrecognized chord, and MusicXML tags are generated during parsing for inclusion in the chord description. This allows unrecognized chords to be exported to MusicXML using the same mechanisms as recognized chords.
A new method is provided generate a chordname directly from a MusicXML harmony object. This chordname is then parsed and rendered just as for a chordname typed directly into the score.
also includes a do-over of the general style dialog changes, being more careful not to accidentally alter other parts of file
don't write on change from Standard to Jazz; write customized chords even if generated; write other id-less chords
| // generate missing renderList and semantic (Xml) info | ||
| //--------------------------------------------------------- | ||
|
|
||
| void ChordDescription::complete(ParsedChord* pc, const ChordList* cl) |
There was a problem hiding this comment.
Sorry if I missed it, but I can't find where the HChord for a ChordDescription is created if the ChordDescription is not read from the chord list file. If it's not done, it would be helpful to add a TODO on complete() or to code it here.
|
You are absoutely correct that I don't generate one. And I actually, my initial cut at this did include a placeholder fo do so. But as far as I can tell, no HChord was ever produced even for chords read from the chord id list. It seems to have been used only as a way of handling otherwise unrecognized chords for MusicXML or Harmony Properties, and that seems no longer needed. But I didn't investiate that as fully as I could have. Certainly won't hurt to add the TODO. If nothing else, the HChord seems like we might someday use it for playback. Let me take another look. I'll add another commit later today. |
|
My point was indeed about consistency. Since the object exists in chord description, it's better if there is something useful in it. It could be used for playback in a future version but it could also be exposed to plugins. |
|
Yes, and I now see that an HChord actually was previously being about from the tag - it just wasn't being used for anything except as an aid to MusicXMl import. But since it used to exist, and the object is there, you're right - it would indeed be good to generate this. Conversely, there might be tags in existing scores (due to unrecognized chords from MusicXMl import, or chords constructed via Harmony Properties) that have never rendered properly before, but could now, if we converted the HChord into a name and then parsed it when reading the score. Neither of these should be particularly difficult - especially since there is already an HChord::name(). No idea how well it works, but I'll give it a shot. |
also fixes write of voicing tag to score when custom chord list exists
|
I now generate an HChord for all chords, tested to be sure all chords previously define in chords.xml will now generate good HChords (and this then used to write a voicing tag to the score in cases where the chord list is embedded in the score). I did not add code to deal with degree lists on score read, since that never worked before either. But I did add a TODO for this. |
WYTIWYG chord symbols
This pull request enables "what you type is what you get" for chord symbols as the default mode of MuseScore. The general style dialog now offers a choice between "Standard" and "Jazz" chord styles, with a third option "Custom" that allows you to select a specific chord description file as before if you really want. This pull request includes the necessary new chord description files to support Standard and Jazz styles. These files will not define a chord id list at all, so all chords will be "unrecognized". But they define a set of token-rendering rules that allow these unrecognized chords to be rendered just as well as with any of the existing chord description files. The bottom line is that chords will now be rendered as typed, but with all the nice formatting that was previously available only for the specific chords recognized by the chord description file. Now, just about anything can be rendered just as nicely.
This pull request relies on previous code already merged to handle unrecognized chords well - allowing them to be transposed and rendered well. This pull request also adds support MusicXML export, so at this point, unrecognized chords can now do everything users would expect of any chord. MusicXML import is also added. The changes to support MusicXML actually form the bulk of the new / modified code here. This pull request supercedes various other MusicXML-related pull requests I had made previously (most recently #381 )
Here is a link to an updated proposal / design document describing what is going on in more detail:
https://docs.google.com/document/d/1Q7LXHDSkQb70xmcyquFSiSv_lGbOXMDwzn_24-n7qJw/edit?usp=sharing
This pull request creates a slight conflict with #371 supporting capo chords. If that request is merged before this one, a small change will be needed in harmony.cpp to resolve some overlapping code.