Option for creating stacked chord symbols (chord names)

• 20 Aug 2014 - 23:13

This has not been possible in the past, and I checked the nightly builds and it is still possible.

Musescore uses "/" to indicate the use of a specific bass note, such as "C#/F". But, in some of the music I read, chord symbols - or chord names - are stacked on top of each other, like what is shown the picture I have uploaded.

Is it possible to implement an option for this type of chord symbol in the new Musescore 2.0 development?

Bijlage Grootte
Chord Symbols Stacked.jpg 418.96 KB

Reacties

• 21 Aug 2014 - 05:56

I believe so. Basically, "C#" would be placed directly on top of "F" with a line in-between, similar to how a fraction looks in mathematical equations.

Currently in Musescore, Chords that indicate a seperate bass note look like this:

C#/F

The only way I'm able to achieve this is by creating staff text and within the single text element I can create two lines, like so:

C#
F

...and manually insert a line - from the "Lines" menu in the palletes box - between the two lines. I've tried editing the text and just underlining "C#", but due to which font being used at the time, certain fonts have excess spacing above and underneath text, and make the chord look wrong.

Sorry if this is making it confusing, but I'm trying to make it understandable.

Reply

• 21 Aug 2014 - 08:11

It's possible, if you are willing to work a little. You need to edit the chord description file (see Chord name in the Handbook) to change how chords are rendered. It's not obvious, but if you're at all technically inclined or know someone who is, it should be possible to come up with a custom version that does this.

Reply

• 21 Aug 2014 - 23:52

Try this (an interim measure until 2.0 comes out, I suspect)...

Copy the attached chord file to the directory where the other chord files live (I don't know where this is in Windows but on my ubuntu machine it's in \usr\share\mscore-1.2\styles).

Create a new score..
From the menu choose Style>Edit Text Style>Chordname and set Y to -4.00sp then [OK].
Reload the file (save and re-open it to let the style take effect)
From the menu choose Style>Edit General Style>Chordnames and select fracchords.xml

Bijlage Grootte
fracchords.xml 12.9 KB

Reply

• 22 Aug 2014 - 15:48

It doesn't centre because it doesn't centre. The centring of an individual chord name is dependant on its font and how it is rendered. I didn't centre anything, just added a quick cludge in the form of shifting the x and y offsets of the second chord.

It doesn't underline because - yep, you guessed it - it doesn't underline. I simply replaced the / with __ and changed the position of the second chord relative to the first.

I can't think offhand how to handle all chords within the limitations of the 1.x framework, I'm afraid. A plugin might do it but by the time I have learned how to do that then 2.0 might well be out.

Reply

• 22 Aug 2014 - 16:54

I can think of a way to do it any better in 2.0 either. The whole rendering system is greatly improved, but the basic way we deal with assembling a chord from root, extension, and bass has not changed.

Reply

• 22 Aug 2014 - 19:15

[Since posting this I have tweaked fracchords.xml to remove the need to set the chords to start higher using Style -> Edit Text Style. Simply use the new fracchords file and it sets them higher to start with. See - just more trial and error.]

Do you mean How To do the above by using the fracchords.xml file? Then, yes, of course.

Do you mean How To alter the chord spacing and create your own chord file? I just looked at the stdchords.xml file and derived fracchords.xml by trial and error. I profess no deep understanding of how it all works:

stdchords.xml

:n m:0:-1 :a m:.5:1
m:0:2 / :n :a

fracchords.xml

:n m:0:1 :a m:.5:1
m:-11:-1 __ m:-10:12.5 :n :a

I changed / to __ then changed the x and y values of the offset for __ and for the second chord to get most of the simpler chords looking acceptable. You are limited here to displaying the letter of the chord, having b and # converted to the flat and sharp accidental symbols, using characters to represent the score or underline and to simple linear re-positioning of the components. An augmented (in the main program code) or entirely different method of chord representation would be needed to do more.

"Tweaked" fracchords.xml

m:0:-10 :n m:0:1 :a m:.5:1
m:-11:-1 __ m:-10:12.5 :n :a

Bijlage Grootte
fracchords.xml 12.91 KB

Reply

• 9 Dec 2014 - 22:47

I can probably assume there hasn't been any work done to figure out a way to achieve this request, but are there any new thoughts or ideas on it?

Maybe I shall submit an issue (feature request) for this and see if something happens with it in the future.

Reply

• 9 Dec 2014 - 23:07

I can definitely see something like this happening in the future (read: after release of 2.0), but for now, using the cusotmized XML file posted above (perhaps with further customization) is the best way to achieve this result should you deem that to be important. FWIW, though, most publishers, guides, and other sources recommend *against* this type of notation, unless your intent is to notate a true polychord (bottom note signifies an entire triad, not just a bass note).

Reply

• 9 Dec 2014 - 23:35

My purpose for this type of notation is purely because the music I work with in the ministry I am a part of uses this type of notation regardless if it's a polychord on the bottom. I never created the original music, but since I took over the music department I see this notation used all the time and would prefer continuity over change of this particular notation.

However, for my own benefit, I have not been able to find anything regarding this type of notation, other than a manual for finale that shows how to notate it using their program. Can you show me what source you have found that says they do not recommend it? Just curious. I don't have a problem with it. I just want the knowledge and reasoning. Thanks for the help, BTW.

Also, I found this issue posted in 2011 that I think is similar to what we are trying to achieve. If not similar, I think I'll submit a new issue (feature request) so we can track it's progress.

Reply

• 9 Dec 2014 - 23:58

Sources include the definitive reference chord symbol notation - Brandt/Roemer's "Standard Chord Symbol Notation" - as well as the published guidelines and actual published music from major publishers like Hal Leonard, Warner Bros, Sher Music, etc, as well as virtually all arranging textbooks I have encountered. It's used the world over, so most musicians are more accustomed to it than to the vertical style. The reasoning, I assume, is what I said - vertical notation is how true polychords are notated, so most publishers and sources have settled on a more horizontal (with maybe some vertical offset) to avoid possibility of confusion. Also maybe horizontal space is less at a premium than vertical space in many scores.

Reply

• 23 Apr 2015 - 05:08

Sorry for the bump, but it is after 2.0 so just wanted to check the status of notating polychords with horizontal lines.

I want to reiterate that stacked polychords should be notated with a horizontal line while diagonal slashes are reserved for indicating a different bottom note instead of the root. Wikipedia seems to agree (see http://en.wikipedia.org/wiki/Polychord vs. http://en.wikipedia.org/wiki/Slash_chord). It is entirely possible for both polychords and slash notation to be used in the *same* chart or even in the *same* chord (e.g. polychord where each chord may be inverted or have a different bass). Also the "poly" in "polychord" means that there may even be more than two chords stacked ontop of each other. Simply modifying a chords xml to render all slashes as horizontal lines will not do the trick.

Also I'm finding that the current fracchords_0.xml does not seem to work well in 2.0, as I'm noticing flats being rendered as blank squares. I'm also noticing if the lower chord is anything other than a major triad, that what I want to be rendered as a polychord gets rendered just with a slash, but the bottom part of the polychord could be any type of chord with any alterations like any other typical jazz chord.

Again, as I said in my earlier issue from 2011 (https://musescore.org/en/node/12515), I'd be willing to code this in, as I occasionally run into charts where this is needed, and want to be able to say that musescore can handle and understand stacked polychords natively. But I don't know where to start and need some permission about how to probably write the chords in ascii. I would suggest using underscore "_" to indicate a horizontal line between chords of a polychord, that way it doesn't conflict with the "/".

Reply

• 23 Apr 2015 - 05:44

If you'd like to give it a shot, the relevant code is in harmony.cpp. See the Development in link in menu at right if you haven't build MuseScore from source before.

The trick is going to be figuring out how to represent this internally,. Right now, a harmony object has a single root, a single bass note, and a singe extension. I guess you'd need to add a secondary extension for the bass note, and perhaps a scheme to allow more chords stacked.

Reply

• 24 Sep 2015 - 03:44

yes I'll try to submit a tentative solution using underscore "_" as divider between two chords in string to indicate stacked chords.

It was always a low priority since there are workarounds.

I will need to figure out the best way to modify harmony.h. Since each chord of a stacked chord is a complete chord in-and-of-itself, I would want to be able to have ability to for instance have a slash chord be above another chord, eg: "Cma7/G_C#5" to indicate a 2nd inversion Cma7 in right hand played over a C# & G# in left hand, and be able to continue stacking with "_". One way I was thinking was to have Harmony become a linked list where Harmony has a Harmony* next, which if null would mean it is just a regular non-stacked chord. Or I could make a derived class StackedHarmony which extends (edit: uses an identical template as) Harmony but which contains a list of chords. The draw/rendering function in either case would do render for each chord at appropriate vertical offset and with line in between. Any immediate thoughts on that before try implement, or maybe you can suggest other simpler solutions?

Reply

• 24 Sep 2015 - 04:01

let me enumerate a third possible way to modifty harmony.h: Make new class HarmonyNonStacked, which would get most of the code currently in Harmony. Then Harmony becomes primarily just a holder for a QList of HarmonyNonStacked objects and would have its draw/render functions call the invidiaul HarmonyNonStacked objects.

Reply

• 24 Sep 2015 - 04:09

(maybe a better name for HarmonyNonStacked like HarmonySingleChord, or just HarmonyChord).

while I'm brainstorming about how I would change harmony I also wanted to consider whether I should try to incorporate the ability to cleanly represent alternative chords or when you intend different chords be played on repeats during solo than when you play melody. Currently my workaroud is to just create two chord objects on same tick, give the first one a higher vertical offset, and then put the alternative chord in parenthesis. It seems would share a lot of the same rendering code if I implemented that feature along with stack chord feature.

Reply

• 24 Sep 2015 - 04:28

sorry for the brainstorming messages. One other though is if I should allow user to enclose an entire stacked chord within parenthesis...so for example should I permit "Cma7/G_C#5"

complex_chord_example_slash_underscore.png

to be fully enclosed in parenthesis "(Cma7/G_C#5)" like:

complex_chord_example_slash_underscore_paren.png

That would complicate breaking Harmony into a list of HarmonyChords, since would also need to render the outer parenthesis, and would need to parse the string to understand that the first parenthsis doesn't belong to the top chord, but to the entire stacked chord.

Reply

• 24 Sep 2015 - 05:56

I noticed that currenlty pressing the return button on keyboard when entering chord doesn't do anything. I'm thinking that if I incorporate an alternative chord feature as well as the stacked polychord feature together, than maybe I could use the newline ascii character '\n' to indicate to place the next chord below without a line, while using '_' to designate stacked chord. So I could type "C\nCma7/G_C#5" (where '\n' is a return) to render as:

complex_chord_example_below_regular.png

so would break into 3 different HarmonyChords: "C", "Cma7/G", and "C#5".

Reply

• 24 Sep 2015 - 14:25

I like the ida of finding a relatively low-weight way of doing this - no new classes, etc. not sure what that means, but maybe something like, just adding a single flag to Harmony to indicate "stacked", which when rendered automatically gets a vertical displacement and optionally (OK, a second flag for this) the horizontal line. So a stacked polychord would just be two chords on same segment but one of which is set to "stacked".

So then becomes just a matter of how to set that flag, and sure, maybe pressing Enter or "_" could do it. Maybe either key would set the "stacked" flag, but only "_" would also set the "draw horizontal bar" flag.

Reply

• 24 Sep 2015 - 19:44

ok, good point. I'll try implementing solution by just having the component chords just be different chords on same segment. I'll try adding a stacked flag and a draw horizontal bar flag. (Or might not even need to create flags cause could just look at final character of string and test if it is a newline char or underscore char.) When saving the file, either would need the flags saved (or would have to save the entire string inputted string). Would mean a new file format version, I suppose, but since 2.1 will have a new file format anyway, now is a good time.

I am wondering if there may be an issue with ordering of chord in the segment, but I'll look into that (if I have a guarantee that chords always remain in same order as inputted inside their segment, then I suppose should be ok). I suppose when calculating the vertical offset of a chord that is part of a stack, that would need to look at all other chords in that segment and count how many are stacked and which order a chord is in its corresponding stack. Might also need to figure out the widest chord in a stack and use that width if want to make the smaller chord names in a stack be center-justified like:

center-justified.png

Instead of left-justified which would happen if I didn't make any horizontal adjustments:

left-justified.png

Reply

• 24 Feb 2016 - 08:52

I jut realized that in addition to the options horizontal line (which is the feature being requested), and forwardslash (which is currently in mscore), I want to also allow the option for *diagonal* (45-degrees) slash, as shown in this example of a published leadsheet for "Compared to What":

compared-to-what_example-of-diagonal-slash-chords.png

I've only provided a small relevant part of the chart (so I don't infringe on copyright), which shows why it is useful to use diagonal slash if space is tight (esp. in cases Db/Ab where chord symbols are on subsequent eight notes).

I am actually know considering if horizontal lines & diagonal lines are really just special cases of a more general feature to have a line at any arbitrary angle. I can imagine situations where space is tight where might want to use different angle than if space is ample. So the angle would simply be a tune-able parameter.

Sorry for the bump, and sorry for not following through with implementing this feature request, yet...

Reply

• 24 Feb 2016 - 21:05

Would you want *all* slashes to be that angle for the score, or would you want to be able to edit the angle of the slash for individual chords?

At some point, we really should allow all aspects of the rendering of chord symbols to be editable from the UI. That is, how much superscripting for extensions, how big the "sus" should be, etc. This could also include specifying how the slash is rendered, and the relative heights of the mainc hord symbol and the bass note.

Werner had implemented a pretty cool chord symbol editor that was very promising was unfortunately wasn't really compatible with the changes I made to to make chord symbol entry more flexible - his editor still relied on the fixed set of chord id's. So we ended up hiding it behind the "-e" command line flag (which enables experimental features), but if you start MuseScore with that option, you'll find it under the Style menu. It *does* kind of still work, but has issues, as you might expect since it was never really tested fully even before my changes.

I have envisioned having a "canonical" chord symbol you could edit in this - one like C7b9sus that includes a root, extension,. alteration, and other text - so you could set the default rendering for each of these generically (eg, it would also apply to Cmin9b13). And then providing overrides for each chord individually. Something like that. And some day if I have time, I do hope to look at that. But if you are itching to improve chord symbol rendering, I think this is the logical place to start.

Reply

• 24 Feb 2016 - 22:35

>> "Would you want *all* slashes to be that angle for the score, or would you want to be able to edit the angle of the slash for individual chords?"

Both just individually and for all chords. Note: currently I'm able to change the *text style* of an individual chord by going in inspector and using a different text style.

Thanks for telling me about werner's editor...I'm trying that out now, and I see that I can adjust the offset of the triangle for maj7 chords in it and all my maj7 chords are updated, and likewise with positoin of 6/9. This seems very promising place to start. I see he has options to save and load chord styles as .xml. Regarding individual vs all, I'd like to be able to individually configure a certain chord or subset of chords for the situation where I may want to use a different angle when dealing with a section with little space between chord symbols. Again, would be nice to select that in inspector, just like we can already change text style on individual basis.

I see that editor is in the files mscore/harmonyedit.{cpp,h}, so I'll start modifying that. I see 4 tabs on the right that are identicial on my machine, and each tab corresponds to a "foreach(const ChordFont& f, chordList->fonts)", so I'm guessing that is so can see how chord symbol looks with different chord symbol fonts.

Regarding for backwards-compatilibity rendering concern, I suppose I won't change the previous default rendering behavior of bass letter.

(Note that all I say above is still seperate from my feature request to have stacked polychords, which now I think will be different than modifying the bass note offset and slash angle. But I will work on this chord symbol editor first.)

APPENDUM: I will need to introduce the concept of an aribitrary diagonal line into this chord symbol editor...I see currently that is simply using the font glyph for forward slash "/".

Reply

• 25 Feb 2016 - 01:39

The main issue with the chord symbol editor as it exists is that ot is tied to specific chord id"s. So yes, if you change the position of "maj7", it affects all maj7 chords, but not maj7#11, or min7, etc. Similarly, you can set the position of b9 in C7b9, but that won't help with C7#9, Cmi7b9, or C7b9sus, etc. Formerly each chord needed a hard-coded set of rendering rules, but now we do this alogirthmically, by parsing the chord symbol and applying a set of context-dependent rules to the different tokens (see for example chords_jazz.xml). The chord symbol editor really needs tp be made aware of this new way of doing things, but it's not obvious how that should work exactly.

Reply

• 17 Jan 2018 - 12:27

One similar thing that shows up with 'oddball' jazz chords frequently in other engravings are that something like C7(b13)(#9) would be rendered as 'partially' stacked in that the b13 and #9 would be on the right of the C7, perhaps in a smaller font, and stacked vertically. Also, when this is done, you normally lose the ( )'s around it. Not sure if this is doable or not, but it would be a nice feature if you could clean up what gets into a real estate problem with such long (horizontally) chord spellings, especially when they happen near a bar line.

Bijlage Grootte
Screen Shot 2018-01-17 at 2018-01-17 06.26.41.png 11.44 KB

Reply

• 25 Jun 2019 - 16:43

New user here. I realize the discussion above is regarding MuseScore 2, but now you are on MuseScore 3. Is there a native solution for all of the possibilities mentioned above? I was not able to find them.

For the kind of writing I do, this is the biggest limitation to the stock MuseScore program (assuming these options are still not native in MuseScore 3).

So any news? Any updates? I haven't yet tried the "home-brew .xml" solutions, but will very soon, if there is no native solution currently, or on the horizon.

Love the ideas though, and I'm looking forward to seeing all of the changes mentioned in this thread above!

For now, instead of delving into the "home-brew" solution, I got the attached results just by entering three separate chord symbols and positioning by hand.
Are there any unforeseen downsides to doing it this way? with transposition? or with auto-positioning? etc.?

Thank you!

Bijlage Grootte
Screen Shot 2019-06-25 at 11.48.26 AM.png 15.5 KB

Reply

• 2 Mrt 2021 - 11:09

Hello, I have a very simple way to do this. Let's say I want to notate Gb7 over an Ab7 on the first beat of the first bar.
1. click the note on the first beat of the first bar, then Cmd+K, then type 'Ab7'.
2. Press enter, then press the same note on the first beat of the first bar, and then type 'Gb7'. after that underline it.

Another way is you use the 'text' tool to type in manually.
1. use text tool to create a text box, type 'Gb7'.
2. press enter to go to the next line and type 'Ab7'.
3. underline Gb7.

Hope you find it helpful.

I wanted to download the fracchords.xml by underquack but when I click into the link it says no file was associated with it. Anyone?

Reply

• 11 Mrt 2021 - 17:26

I see you have had no response to "I wanted to download the fracchords.xml by underquack but when I click into the link it says no file was associated with it. Anyone?" yet.

I suggest you start a new thread devoted to your question rather than burying it this thread.

Reply

• 11 Mrt 2021 - 19:29

The normal method is the Inspector, and it works, except it doesn't know how to handle the special formatting in "Jazz" style. So depending on your special reason for underling chord symbols (it's not standard practice), you might need a different method. Feel free to describe your use case in more detail, ideally with a sample score.

Reply

• 20 Feb 2024 - 10:49

Hi, I don't know if anyone there will be still active, I just used underquark's solution and it works, however only for major chords... If I write a-/g-, or am/gm, the fraction notation goes away and the slash appears again, as a bass notation. Does anyone have a solution for that ? Thanks !

Reply

• 20 Feb 2024 - 13:20

Those are polychords, not simply slash chords. MuseScore has no built-in support for this, but it does work to simply enter them individually. Easiest to do so bottom up - first the bottom chord, then a horizontal line, then the top chord. MuseScore will then stack them in the reverse order.

Reply

• 23 Feb 2024 - 18:02

Hi, I modified the render base, I get the stacked for the G7/B for example.
:n :a
m:-11:+2; s_ s_ m:-10:11.5 :n :a
where

I like the slash as it is most of the time, but in some cases, I would rather have it stacked.(even if it is "improper"... my music is not really going anywhere other than some of my friends... :) )

SO
would it be possible to modify and XML to allow for "/" function to work as normal, and add an "_" modifier that would call a different renderBasexx for the base : Stacking them up as with the modified renderBase?

and they could be played the same way ??
...
I did not find any information on how add a "render" functions
I realize there is a new renderfunction in version 4...
thank you

Reply

• 23 Feb 2024 - 21:16

No, there is nothing like that, you'd have to pick one or the other. At least until someone implements new functionality in MuseScore itself. BTW, not sure what you mean about something new in version 4, but to be clear, there are no relevant differences at all - this code wasn't really touched at all. Some preliminary work was done to eventually allow for more flexibility within the program, but it was put aside until later.

Reply

• 24 Feb 2024 - 16:02

what I meant was nomething "new" maybe different? in .xml style files... ( it seems my previous comment was sent away ... :) ) so I repeat....

in musescore 3 in chords_std :

renderRoot :n :a m:0.5:0/renderRoot
renderBase m:-0.2:1 / m:0.2:1 :n :a m:0:-2/renderBase
and in version 4
renderRoot :n :a m:0.5:0/renderRoot
renderFunction :a m:0.5:0 :n /renderFunction
renderBase m:-0.2:1 / m:0.2:1 :n :a m:0:-2/renderBase

And I was wondering if the program could call a different rendering modifier (coming from the .xml file) depending on how the chord is spelled.

C69 has three different ways to be displayed depending on the way it is defined..
C69 C6/9 C6,9

couldn't it be similar for
G7/B - diagonal
G7_B -vertical
G7|B - horizontal

as defined in musicxml 4.0
https://www.w3.org/2021/06/musicxml40/musicxml-reference/data-types/har…

Thank you

Reply

• 24 Feb 2024 - 16:26

renderFunction was been present in MU3 as well - at least, since whenever we added support for Roman numeral analysis, maybe around 3.2. Not used for chord symbols.

The handling of "/" is done within the actual MsueScore code - that how MuseScore knows which render statements to use. There simply isn't handling for "|" - it would have to be added within the code. A reasonable request, but not trivial to implement, and more likely it would come as part of the broader re-design for chord symbol formatting options that was begun a couple of years of ago but then put on hold.

Reply

Do you still have an unanswered question? Log eerst in om je vraag te plaatsen.