There often seems to be a discrepancy between what appears in the Edit Chord Symbol Component window and what appears in the Project Default Chord Symbol Appearances window, making it difficult to get everything to align correctly. Here’s a simple example:
Because the comp.chordsymbol.kAltered.9.kSharp composite uses a level baseline for both the sharp and the 9, it appears visually unbalanced. The easy solution is just to delete the default composite, and create my own using comp.csymAccidentalSharp and a 9 in the Edit Chord Symbol Component window. However, when it looks correct in this window, it looks drastically different in the Edit Chord Symbol Component window and in the actual music.
When it looks like this in the Edit Chord Symbol Component window …
… it looks like this in the Project Default Chord Symbol Appearances window and in the actual music:
In order to get it to appear correctly I need to do something like this:
This is just a simple example, if that’s all I needed to do, I probably wouldn’t worry about the discrepancy and would just work around it to find what displays correctly. Unfortunately, this problem becomes even worse when multiple symbols are involved, to the point that it’s impossible to get everything lined up correctly.
If I try to edit a chord suffix with multiple alterations like alteration.stack.1.primary which is used in a #9#5 chord, Dorico is treating the X and Y alterations of identical symbols differently. In this gif I have added 2 comp.csymAccidentalSharp symbols. When I change the Y value of the first they are being moved vertically by different amounts!
Once two more glyphs like the 9 and 5 are added, the situation becomes very unworkable with a negative Y value sometimes even showing a positive movement on screen and vice versa, making it impossible to align everything correctly. I’m not really sure what is going on in these situations but it would be great if this could be fixed so what is in the Edit Chord Symbol Component window is reflected in the Project Default Chord Symbol Appearances window and the music.
Can you attach a simple project containing the chord symbol in question? I have two guesses, but (as I am wont to say), I wouldn’t have to guess if I could try it for myself. The first guess is that your components are in the wrong order: if you want to exchange the sharp glyph, make sure you remove both the # and the 9 and then add the # before you add the 9: if you remove the # and then add the new #, then position it left of the 9 though it’s attached to the right, bad things can happen. The second guess is that you may have inappropriate attachment options set on the ‘Attachments’ tab in the editor.
Hi Daniel,
The file seems to be irrelevant. I get the same results starting with any default. Here’s a file starting from New from template/Solo/Solo piano, with the chord symbol for C7#9 edited. Thanks for checking this out!
Chord test.zip (423 KB)
… and just to clarify, here are the settings:
I confess that as yet I’ve been unable to work out exactly what’s going on here, but I don’t find tha I get the same kinds of results as you in a new project. When you create your own e.g. #9 component, make sure you use the accidentals from the ‘Standard accidentals for chord symbols’ group (you’ll need to scale them down), then add the existing ‘9’ from the ‘Text’ tab, and you should find that the positioning is reliably the same between the dialogs and the music itself. It is for me!
I know I’ve reported this already, but I think I finally realized why the chord editing window is not WYSIWYG when trying to edit composite chord suffixes. Here’s the standard shipping #9 composite alteration:
Because the # and the 9 share a fixed baseline, the symbol appears unbalanced, and the descenders of the # really should extend below the baseline of the 9 to appear visually balanced. To modify the #9 I click the Edit Component button, open the Edit Chord Symbol Component window, delete the comp.chordsymbol.kAltered.9.kSharp character, and rebuild it using the comp.csymAccidentalSharp and a 9 using the font.chordsymbols style. After positioning them to be more visually balanced I end up with something like this:
However as soon as I hit OK to close that window, this is how it appears in the Project Default Chord Symbol Appearances window and in the score wherever it is used:
The sharp appears correctly, but the position of the 9 is way off from where it just appeared in the editing window. Because the Edit Chord Symbol Component window is therefore not WYSIWYG, it is very difficult to adjust composite chord symbol suffixes. With 2 characters such as #9 it can be done with trial and error, but with 4 characters such as #9#5 it’s virtually impossible to get everything lined up correctly.
None of the above is new and has been reported already. What I realized today is that I think Dorico is incorrectly applying the default X and Y offset that appears in the Project Default Chord Symbol Appearances window to each character in the suffix, rather than to the composite as a whole after it has been edited. In the above example the # appears correctly and the position of the 9 is incorrect, but if I set the X and y offsets to 0, then the # is positioned incorrectly and the 9 is now correct (or close to it):
Could that be what is causing this bug? If so, it would be great if Dorico could treat composite chord suffixes as a single composite after they have been edited rather than applying the default positioning to each character in the composite. Or is it still something else that is causing the discrepancy between the two windows?
I’ve moved your new post back to the original thread, and I’ll take a closer look to see if I can corroborate your findings as soon as I get a chance.
Great, thanks! I’m curious if the error is in fact because Dorico is sort of double-applying the offset values once the composite is edited. If not, I can keep playing around with it to see if another pattern emerges.