Final (?) changes for chord symbols
As described here , I implemented a brand chord symbol parsing and rendering scheme for 2.0 a few months back. As far as I can tell, it's been working very well, and now I'd like to tie up a couple of loose ends.
First, I want to eliminate the old Harmony Properties dialog (now renamed Chord Symbols Properties), accessed via right click. It no longer works - due to the new scheme in which there are no predefined chord ids, all chords show up as "other", and attempts to change the extension via radio buttons have no effect. While it would be technically possible to fix the dialog, it would be extra work and I don't see the value of it. One of the only reasons I could see to use this dialog in the past was to get around the fact that it was hard to guess how MuseScore wanted you to spell certain chords, but it's no longer necessary to guess right - pretty much anything you type will be understood. Unless someone has a good use case for where this dialog really provides value, I'd like to remove it
Second, I want to move the Chord Symbols Style Editor (which was added relatively early in the 2.0 development cycle) from Style / Chord Symbols to a less prominent place, probably accessed by a button within Style / General / Chord Symbols. The Editor does provide a nice facility for fine tune the rendering of individual chord symbols in terms of the positioning of the various glyphs (to change superscripting, etc). Although the new rendering facility I added does provide a way of doing this by customizing XML files, the GUI approach is obviously better for most. But it's a bit misleading to have it where it is, as it makes it seem like this is the main place where you change chord symbol rendering. It isn't. The most important options - the only ones I think most users would ever need - are in Style / General / Chord Symbols and/or Style / Text / Chord Symbols. The Editor is more for individual tweaks above and beyond those basic settings.
Also, FWIW, the Editor does not currently work correctly for chord description files that involve glyphs of multiple sizes, as is the case in the "Jazz" style. I believe I've encountered other bugs too. I'd want to fix these as well (or convince Werner to :-). If that proves more difficult than it's worth, it wouldn't break my heart to see the Editor removed for 2.0 until it can be fixed.
Comments
A couple more things:
I have never been comfortable with the fact that there are two sets of style settings for chord symbols (general and text) but I don't see an easy way around that. However, right now there is a conflcit between the Y position in the text style and the height in the general style. The latter is a new addition for 2.0, and I'm not 100% sure if it needs to be there or not. But if it does remain, I think it should be an offset that is added to the Y position specified in the text style. Analogous, I think, to how lyric upper margin combines with the lyric text style Y position. Currently, for chord symbols, general style height overrides the text style Y position completely, making the latter ineffectual. At this point, I could go either way (remove general style height or make it additive with text style Y), but I'd like to make the call and do it soon.
Also, Tony Mountifield did some great work a while back in getting an automatic capo facility working, then redid that work recently to bring the code up to date after all of my chord parsing/rendering changes went through. I guess the Travis build failed on his pull request - probably on account of tests that would need to be updated - but I assume the code basically works. If there is consensus that this is worth doing - and I for one think it is - then I'd like to do whatever it takes to get the Travis build working and see the PR merged.
One more thing:
It has been suggested that "h" be accepted as a shorthand for half-diminished. Currently, I use "0" (number 0, which once upon a time was commonly represented with a slash through it). It's easy enough to add "h" as a synonym, but I have some concerns I'd like feedback on.
- "h" is used in the new figured bass facility to mean "natural". Presumably, this is because the shapes are similar. I wonder if this convention is standard at all? Anyhow, currently, chord symbols include no representation for a natural sign - they aren't normally used. But I am reluctant to introudce unnecessary inconsistencies.
- "h" is a natural shorthand for half-diminished in English. Probably not so much in other languages.
- Roman numeral analysis seems like it would be a natural choice to some day add to the figured bass facility, since it shares things like the vertical representation of numbers in symbols like IV64. Right now, figured bass doesn't use the half-diminished symbol, but if Roman numeral analysis were added, it would need it. Again, I'd like to plan for consistency.
- Ultimately, I plan (probably for the next release *after* 2.0) to add a shorthand customization facility, so you can specify what abbreviations you'd like to use for major, minor, augmented, diminished, and half-diminished above and beyond the "standard" ones. So you could do things like say you want "dur" and "moll" for major and minor, etc.
For these reasons, I'm thinking I'm *not* going to add "h" for half-diminished right now. But I do invite discussion, particularly about the Roman numeral analysis possibility.
In reply to Shortcut for half-diminished by Marc Sabatella
I'm OK with not having 'h' as a half diminished shorthand now.
As long as there is another one-key shorthand ('0') available, it's fine.
And when you eventually add the shorthand customization facility that will be very cool!
Would your cleanup also remove chords.xml?
In reply to Would your cleanup also by Jojo-Schmitz
No. It and all the old chord description files need to stick around for compatibilty - so 1.x scores will still work properly.
In reply to No. It and all the old chord by Marc Sabatella
I'm not talking about stdchords.xml and friends, just about chords.xml, has this really ever been used at all?
Or is it just the info about which notes are in a chord has never been used, just chodname and ID?
In reply to I'm not talking about by Jojo-Schmitz
chords.xml is *always* used prior to 2.0. It gets loaded in addition to whichever chord description you specify. The two files work in conjunction. The chord files control the remdering, but chords.xml defines the syntax and semantics of a chord - what you type, the MusicXML representation, etc.
As of 2.0, chords.xml will no longer be needed for new scores - just for compatibility.
The info about which notes are in the chord - the voicing tags - is indeed not used for anything in particular that I know of. But the code does exist to read that info and build appropriate data structures.
In reply to chords.xml is *always* used by Marc Sabatella
OK, thanks for the explanation and sorry for the noise