Chord Symbols not displaying (parsing?) properly
I have been building with the latest master code from github since a few weeks ago, and this problem has been there the entire time. I have searched here and github and find no mention of it, so I'm posting this to see if I should enter something in the Issue Tracker.
See the attached file. If you open it in MuseScore 2.0.2 you'll see three chords in the first measure, Em, F and D7. If you open it in the latest nightly build you'll see just "m" and "7".
Is this a currently known issue? Should I submit an official bug report? Never done that before, so I'm being cautious here. Thanks.
| Attachment | Size |
|---|---|
| mm72.mscz | 10.82 KB |
Comments
Are you on Linux and forgot.the 'make.install'?
In reply to Are you on Linux and by Jojo-Schmitz
I'm on WIndows 7. This all works in my 2.0.2 builds, but not in my master builds.
EDIT: In reverting back to 2.0.2 code base I am seeing the same problem there too. Oops. Maybe I am missing something in the build process.
In reply to I'm on WIndows 7. This all by sideways
The "make install" step is not optional on any platform. Without it, you won't get the necessary chord style files. MuseScore needs to find these in the correct place relative to the folder it is being run from, and this happens only if you have run "make install" and are running from that install folder.
In reply to The "make install" step is by Marc Sabatella
Nevermind my previous version of this comment. It works now. I didn't realize that it would build an entirely separate MuseScore.exe. My mistake.
Thanks!
follow-up: Is there a way to turn off the parsing/substitution that goes on in Chord Symbols? I'm thinking I can better achieve the format I desire by using a single font and manually inputting the unicode charcodes for extended chars like flat-sign. I realize I can use Staff Text or something more generic, but I'd prefer to use the intended tool, and I like having it as a separate Element::Type so that I can distinguish it in my SVG files.
My attempts at turning this off completely have failed so far. I even tried setting Appearance to Custom and setting the xml chord symbols style file to empty. I'm hoping there's a way to either turn of the parsing/styling completely or setup a style file that achieves the same result.
In reply to follow-up: Is there a way to by sideways
I am not an expert with Chord Names at all. But telling from other MuseScore aspects with some similarity, I would say that, by not using Chord Names ([Ctrl]+[K]) at all, you would get rid of any automatism on them.
If you have ways to enter and position within the string the characters you need, regular staff text would be enough (in case, you may create a specific text style to set the correct font and position of the string).
Of course, you would loose any automatic management (including for instance, transposition), but this seems precisely what you are after, isn't it?
In reply to follow-up: Is there a way to by sideways
The way to get special=purpose custom formatting of chord symbols is to create a customized XML file that defines the rednering you desire for the different tokens. What is the effect you are trying to achieve?
In reply to The way to get by Marc Sabatella
I prefer them to be chord symbols mostly as a way to distinguish them from other text. Though the transposition is a feature I don't mind keeping too.
I don't think that I can encapsulate the effect I'm trying to achieve in terms of an alternate auto-formatting. So I would like to have it do absolutely no formatting at all. Whatever I type is whatever it displays. Is that possible? Are there instructions for building one of these .xml files?
In reply to I prefer them to be chord by sideways
The fiule is meant to be relativewly self-documenting. But it's more than just the rendering - it's also a question of semantics. The letter "b" is used internally as a placehold for the flat sign. You can force it to be rendered as the letter "b" if you have some unusual special purpose that demands this - some non-standard notation, perhaps? - but internally it will be a flat. So "Eb" would render with the letter "b" insteasd of a flat sign if you configure the XML file that way, but it's an E flat internally and will transpose as such.
I can't help but think that whatever you are trying to do can be done in a much more straightforward way than whatever it is you are imagining. What exactly *are* you trying to achieve?
In reply to The fiule is meant to be by Marc Sabatella
I'm hoping you're right. I like straightforward. I have had some troubles with the auto-formatting in the past, the "b" as flat-sign being one case. There are also some specific types of formats that don't seem to be supported that I'm thinking I need to create inside a font, like 6/4 to 5/3 but with super/subscript right on top of each other - I don't know how to represent it accurately here :-) I'm mixing standard pop/jazz chord symbols with "classical" analytical symbols - I'm not going full Schenker, just traditional symbols. Sometimes I don't even really know what the most appropriate way to spell a chord is, so I make up something or I offer alternatives.
The more I think about it the ability to sub and superscript numbers to indicate chord inversions and extensions is important, and it seems a separate font is important to control the way that sizes and spaces and stacks.
Also, in SVG these end up as multiple text elements because of the mixing of fonts that occurs within a single chord change. It seems that if I create a font that has the alphanumeric characters I need plus all the special chord-related characters, I could simply use that font and everything would be solvable, regardless of some future way I wanted to spell a chord. The single SVG element would be a bonus.
In reply to I'm hoping you're right. I by sideways
For Roman numeral analysis, a custom font is indeed probably the way to go. There is one called SicilianNumerals I installed once that seemed to do a decent job of setting things up like the 64 etc.
Still, it *is* possible to set up the superscript/subscript thing in the XMl file. See how the "Jazz" style handles the C69 chord, for example.
In reply to For Roman numeral analysis, a by Marc Sabatella
OK, and the "b" as flat - there's probably a way to xml the dreaded B-flat flat-9 chord too, right?
The semantic issue of the "b" as flat is something I need to keep in mind. And yes, Roman numerals will be in the mix.
So is there a way to do this with a custom font and zero formatting via the .xml file? If it's not an option that limits my choices.
In reply to OK, and the "b" as flat - by sideways
Not sure what aspect you mean - are you saying you *don't* want the the "b" turned into a flat sign as it normally would, but rendered as an ordinary "b"? It would still help to better understand your unique style of notation. But FWIW, Bbb9 would not be standard notation. Standard notation would require an extension after the root - eg, Bb7b9 - or else parentheses around the b9. Otherwise, both the human musician reading the chart and MuseScore would see this as B double-flat nine.
Roman numerals won't be handled as chord symbols because chord symbols "by definition" start with a root name, and neither I nor V will parse as roots. So the result won't be parseable as a chord symbol, nor should it be - it's something else. You are wlecome to use the chord symbol facility to enter Roman numerals, but since the root isn't recognized, they won't be parsed further. Meaning, "b" stays "b", no way to use the XML file to get nice rendering of 64, etc.
In reply to Not sure what aspect you mean by Marc Sabatella
I don't necessarily have a unique style, I just borrow from different styles as seems appropriate. If you spell the Bb b9 chord with a superscript b9, then it looks OK. In pop/rock music it's referred to as a b9 chord - seem Jimi Hendrix's "Foxy Lady" as the classic example. That and Deep Purple's "Smoke on the Water" are the first two songs way too many guitar players ever learn, even today, >40 years later.
But that would parse normally because I'd be using special font for the superscript flat sign. Once I get the font for the special chars I need maybe this will all work out. If I then specify that same font as my music text font (the slot MScore Text occupies by default) it won't have to change fonts in the middle of the chord symbol. In other words, the "b" semantics may be a non-issue once the rest is in place.
Yes, I'm using "b" for flat here too. It is convenient.
In reply to I don't necessarily have a by sideways
I'm not saying the chord is never encountered; I'm saying that s[pelling it the way you describe is *not* standard and no publisher I know of would do it that way. They would, as mentioned, use parentheses, or specify an extension to help disambiguate. So unless you have some really uniquer special reason to use this non0standard notation, why do it when more standard notation exists?
In reply to I'm not saying the chord is by Marc Sabatella
That's a good question. Maybe I need to brush up on the standards. I haven't been in school for a while and I'm mostly just trying to translate my handwritten symbols to MuseScore. Is there a reference somewhere for the standard symbols, where I can brush up?
But I'm still going to need get that sub/superscript + Roman numerals font happening, right?
And MuseScore Chord Symbols parses parentheses specially too, right?
In reply to That's a good question. by sideways
Well, "standards" is a relative thing when it comes to music notation, and chord symbols especially so. It isn't like there is one universally agreed upon way of notating them. Pretty much everyone does their own thing to some degree, but it does help to look at a variety of scores from a variety of sources to see the range of things that people tend to do. You wouldn 't necessarily need to copy one editor's style exactly - no one would expect that - but others *will* expect that everything you put to paper would be something they have seen before. It might be some aspects taken from one soruce, others from another source, etc, but there really is no good reason I can think of to do something *no one* else does when there are pretty obvious commonly used alternatives that would communicate your intent much more clearly.
In the case of "Bbb9", you are correct that a difference in font / superscripting could make it clear this is "Bb b9" and not "Bbb 9" - the two flat signs would be different sizes or different positions and thus not look like a double flat sign. However, consider something simpler - shall we say "Ab9". Nothing you do with the font on the flat sign would ever be sufficient to completely convince someone you meant "A b9" rather than "Ab 9". That is why there is virtually universal agreement among editors that this is simply not done, and instead you add an explicit extension as in "A7b9" or use parentheses as in "A(b9)".
Now, that said, I believe it *would* be quite simple to make "A(b9)" render without parentheses with just a couple of lines of code in the XML file to force the parentheses to render as a non-printing character. Again, though, that's more work for you and a disservice to the musicians reading your score, and ultimately to you are a composer / arranger, because the musicians will almost certainly play it as Ab 9 not A b9.
In reply to Well, "standards" is a by Marc Sabatella
This issue is back in version 4.0.1. Running the binary on Windows 10.
In reply to This issue is back in… by James Munroe
And is known. See #334422: [MusicXML] Doesn't show chord symbols when open XML file - export fail