Iâm surprised this isnât part of the core feature set. Optional chords are somewhat fundamental for jazz charts. The coding doesnât have to be complicated; just allow one left paren at the beginning and one right paren at the end of the chord text (both have to be present, and only one group â e.g. not (((am7))) â could be displayed ).
Actually, Daniel acknowledged in June 2017 that âparenthesising an individual chord symbol would indeed not be the hardest thing to implementâ.
He did add though that parenthesizing a sequence of chords âis significantly more complex to achieveâ.
I imagine itâs the semantic consequences that have made this anything other than a relatively trivial matter but while itâs laudable to consider how for example, playback might be affected, the complete absence of parentheses for chord symbols (something quite a few people would use all the time) seems a mistake to me. Could the implications for playback not have been dealt with at a later stage? Repeats could be drawn before they would play back so this wouldnât be unprecedented.
Maybe some wonderful integration is being worked on but thereâs a slight sense that this is a blind spot and itâs hard to forget the way parentheses disappeared without explanation from version 6 of Sibelius.
I expect that, knowing what repeat symbols would have to do, the developers had established conceptually how they would implement playback even if they had not written the full coding when they released the repeat symbols. The Team may not yet have established all the ways parenthesized chords should work behind the scenes, and that might be delaying implementing the graphic representationâor the Team may just have items higher on the roadmap.
Whatever they might be considering, the graphic presentation wouldnât change so there doesnât seem any reason to delay. They didnât omit pauses because it wasnât quite certain how playback would be handled. A thread like playback notes in brackets - Dorico - Steinberg Forums suggests that brackets can later be given new meanings if necessary.
I recognize that priorities vary but this is an odd thing to neglect and there have been frequent requests for it. Reading about Petaluma on Introducing SMuFL | SMuFL, itâs mentioned that itâs based on the âstyle of the hand copyists for Sher Publishingâs Real Book seriesâ but the majority of songs in those (admirable) books use parenthesized chord symbols. Itâs an extremely common form of notation.
For single chords the two parentheses should âobviouslyâ be the same height.
But what about a sequence of chords which starts with âCâ on one system and ends with something with several stacked alterations on the next system? Would you want a small opening parenthesis and a bigger closing one? (Probably yes IMO). But if the entire sequence was on one system, maybe you would want both parentheses the same sizeâŚ
And would you want a âcautionary parenthesisâ on the first chord of the second system? ProbablyâŚ
+1, completely agree, itâs very common and definitely should be implemented.
Yep, and I suspect that another complicating factor is that Dorico currently doesnât seem to have any mechanism to allow two chords to occupy the same beat. Sure, there can be local vs global differences, but there is no true way to have two different chords both occupy beat 1 as in this example:
I would imagine any sort of useful parenthesis feature for alternate chords would need to add this ability which probably isnât so trivial to implement.
Before version 6, Sibelius allowed you to write whatever you wanted and offered large brackets that worked well with either a single letter or stacked alterations. Brackets were inexplicably omitted from the âimprovedâ system. The old procedure was still possible if one selected the preference âUse legacy chord symbol inputâ.
It was simple in Sibelus in that you could write more or less anything that you might with pencil and paper.
With Dorico youâre in trouble if the framework canât easily accommodate what you want to do.
Is programming in C simple?
Generally, I find that Dorico is a wonderful tool (Iâm certainly productive) but there are areas where itâs too restrictive.
Itâs of very little value for us users to toss back and forth various conjectures about how easy something is to implement. Make a feature request and make a case for why itâs important. Leave the evaluations to the devs.
Itâs not like weâre going to say ââŚand besides, this is easy to code,â and theyâre going to respond, âGosh, we had no idea!â
I asked about a second line of chords at the same time as I first enquired about brackets (I think it was my first ever post in this forum). The development team has prioritized the sharing of one set of chord symbols between instruments and this certainly saves lots of time and avoids a lot of errors. If they can offer alternative lines with easy parenthesis that would be perfect.
The developers must be well aware by now that plenty of users want to be be able to use this very common form of notation.
Whatâs interesting is that brackets arenât available despite the requests and the acknowledgement that the simplest implementations (if that isnât a contradiction) wouldnât be difficult. That suggests to me that perhaps weâll get a really comprehensive solution in the end (which would obviously be very good news).
Unfortunately, this comes up fairly often with Doricoâs design and implementation of chord symbols. Iâm sure I and others have mentioned all of the following before, but in addition to chord alternates appearing at the same beat and ability to use parentheses, there are quite a few other pretty big issues with chord symbols:
You canât remove a top empty staff from a grand staff instrument if you have chords set to show between staves. I believe the developers have said thatâs because the chord information is internally stored in the top staff, but this is also a fairly common need. From a user standpoint, this ability is very desired and there is no musical reason for this not to exist, just a program design reason. (Somewhat related, thereâs no single staff piano instrument in Dorico without hacking your instruments.xml file. It has been stated one is unnecessary as you can just remove a staff if you donât want it, but of course you canât with this chord setting.)
Itâs impossible to globally have a phrygian chord display as âG Phrygianâ unless you take an entirely unrelated chord that is unused elsewhere in the project and manually redefine it to be âPhrygian.â You can of course change every individual instance, or create Project Default Appearances for every possible root, but this is certainly a time consuming workaround for something that should be easier. There really should be more settings for modal chords.
There is no chord accidental baseline setting for roots. This means that a sharp or flat modifying the root will share the same physical baseline rather than optical, and Doricoâs chord symbols with roots using accidentals often appear unbalanced by default. Thereâs a workaround to globally modify the sharp or flat character used, but most users arenât going to dive in that deep without an easy way to change this setting. This is a simple setting to modify in Finale:
There are no accidental baseline settings for suffix alterations. This issue is way worse than the root issue because the Edit Chord Symbol Component window is super buggy and not at all WYSISYG. Iâve reported about this in depth before, but basically this editing window is only reliable for single glyphs or composites once you apply any sort of vertical modifications. If I balance the baseline so it looks like this in the Edit Chord Symbol Component window âŚ
⌠it will look like this in the next window and in the score:
A lot of wasted time with trial and error experimentation is required to create even simple suffixes with any sort of balance in this window. For example, take the Coldplay - Clocks example score that ships with Dorico, enter a C7(#11), then see how much time and how many steps it takes you to make the sharp legible and fix the kerning on the 11. Basically turn this
into this
There is no baseline setting for stacked chords. If you want a level baseline, you have to make manual Y edits to every single chord because the Edit Chord Symbol Component window is too broken to make a global change here with multiple suffixes. Personally, in this example Iâd like stacked chords to have an even baseline like the C7 instead of offset like the F7. (Even here in this example the sharp is unbalanced.)
Thereâs no Erase Background for chords. This is needed in virtually any big band score that doesnât have a lead player as the soloist. Again, thereâs a workaround using text with a non-breaking space, but this is also time consuming for something that should be as simple as a Properties checkbox.
Chord Symbol Regions are literally the only element in the Write menu that produce a different result when created vs when copied. Creating one in Write also makes a change in Setup to enable the chords to display. Copying one in Write doesnât make this change so the purple bar displays on screen, but no chords. This action should produce the same result whether created or copied. It would also be nice if they could be applied to multiple staves at once.
There are probably other things Iâm forgetting too, but when all these issues are taken as a whole, they can often make using chord symbols a very frustrating experience for the user. I know Doricoâs chord symbol concept is different from other programs so I wouldnât expect it to necessarily work the same, but having multiple chord symbols on the same beat, and issues 1-5 above are all non-issues in Finale. (Finale also requires some workarounds like text for parentheses and to erase background.) I would love to see some of these addressed in v4.0!
If one could choose where to set the anchor of a text (or other) item and choose the chord symbol in question, the parenthesis would move with the chord symbol. Anchor targets could be the page (I think thatâs how text items are anchored now), a system, a bar, a note â or a chord symbol â or even another text itemâŚ