chord symbol in parenthesis feature request

+1 Please!

+1

+1

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 ).

1 Like

Somewhere a developer just fell down dead…

offering bad, unsolicited coding advice is my specialty lol

Perhaps we should start suggesting that those who think the coding is so simple should reprogram their copy of the software themselves. :laughing:

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.

I thought there was already a project doing that, called “Musescore 4.0” :slight_smile:

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…

It’s not at all simple IMO.

+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.

1 Like

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!” :nerd:

1 Like

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:

  1. 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.)

  2. 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.

  3. 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:

  1. 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

  1. 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.)

  1. 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.

  2. 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!

3 Likes

Nice write-up!
I’ll second this… :+1:

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…