Incorrect Sharp/Flats in Chord Symbols
I'm creating a chart using Inkpen as the font style for all text & chord symbols (trying to match previously created charts). When I enter a chord with a sharp in it, the correct font symbol shows (fig. 1), but when I commit the entry it turns into a "generic" sharp symbol (fig. 2), not the one from the font (Inkpen2 Chords Std). This happens with flat symbols too.
I've got Inkpen2 Chords Std designated as the chord symbol font in Format->Style->Text Styles and it seems to be working OK except for the sharps & flats.
Any ideas on how to make the Inkpen2 Chords sharp symbol persist here? Thanks!
Comments
Are you wntering the sharp sign as described in the handbook - by simply typing "#", not using any sort of special font-dependent code? If Inkpen2 follows the standard Unicode SMuFL layouts for musical symbols, it should work perfectly. Otherwise, if the font is non-standard, you will need to find or create a custom "chord description file" to use for it. Given that MuseScore already included two very nice handwritten-fonts of its own (MuseJazz and Petaluma Script) that do follow the standards, you might simpler to just use one of them.
In reply to Are you wntering the sharp… by Marc Sabatella
Hi Marc, thanks for your reply. I am simply typing shift-3 to make the hashtag. The puzzling thing is that it displays as it should during entry, but turns into something else upon finalizing the chord. I'm not sure if the font is in the standard SMuFL format, it was installed when I installed Siblelius a while ago. I'm trying to move away from that program but have several projects mid-stream that I would like to keep consistent which is why I am attempting to stick with their hand-written font for now.
In reply to Hi Marc, thanks for your… by Al Loast
It's not puzzling if the font is non-standard. We deliberate yhcnage the plain "#" sign into a real sharp sign, using the standard Unicode and/or SMuFL codepoints. My guess is Inkpen is designed to work with programs that don't know about these standards and thus only provides a sharp sign a the "#" codepoint and not at the proper Unicode or SMuFL codepoints. Perhaps a more up-to-date version of the font might be better in that respect. But otherwise, I guess you could install a font editor and copy the symbol to the proper location.
I think you'll findthe notation fonts themselves different enough between Sibelius and MuseScore that a slight difference in appearance of the chord symbol fonts mighty not be so noticeable in practice. But I haven't done a detailed comparison. Could be interesting to see a side by side showing one of your charts in Sibelius using Inkpen and whatever your preferred notation font was vs one in MuseScore using MuseJazz or Petaluma Script and the corresponding notation font.
In reply to It's not puzzling if the… by Marc Sabatella
I opened up both Inkpen2Chords and Petaluma in a font editor, and they both appear to have the # sign in the correct place. The Inkpen font is in an OTF file format, I'm not sure if that's exactly compatible or not. I've been able to replicate my preferred Sibelius handwritten style pretty closely in Musescore but this sharp sign issue is being quite bothersome. :)
I've attached font charts for both fonts for your reference.
In reply to I opened up both… by Al Loast
Just for reference, here is a sample of lead sheet notation in sibelius & my musescore inkpen style for side-to-side comparison. It's pretty close! I understand clefs can't be changed independently of the music font but otherwise it's pretty close. Except for those darned sharps & flats!
In reply to I opened up both… by Al Loast
As mentioned below, those screenshots show the "hash" character codepoint, not the SMuFL "sharp" codepoints
In reply to As mentioned below, those… by jeetee
Your replies gave me the info I needed to make a fix. I used the opensource font editor FontForge to open my .otf font file, and pasted the sharp, flat and natural signs into the correct unicode positions (U+266D thru U+268D). I also changed the name of the file in the info fields and then exported it as a new .otf and added it to my Library->Fonts folder.
I reloaded my test score and changed the Chord Symbols style to use my new font. It works! Sharps, flats and naturals now appear as they should in my score. Much thanks!
In reply to Your replies gave me the… by Al Loast
Nice.
Just keep in mind that this works only for you and for image exported formats. Unless you also distribute your modified font file for others to install (which might or might not violate the font license, so make sure to verify that!).
In reply to Your replies gave me the… by Al Loast
Hello, i have same problem with flats and sharps, please, can you send me fixed Inkpen Jazz font or xml file? Thanks in advice
In reply to I opened up both… by Al Loast
This shows the regular # sign, not the sharp one
In reply to This shows the regular #… by Jojo-Schmitz
Time to wake up ;-) You're late to the party :-p
In reply to Time to wake up ;-) You're… by jeetee
Need more coffee...
In reply to Hi Marc, thanks for your… by Al Loast
It is showing the "hash" character during text entry.
It is showing the "sharp" character after being parsed. The shown character doesn't immediately look like the fallback character I'd expect, so likely that is the "sharp" character from your font.
In reply to It is showing the "hash"… by jeetee
Since this is just text, I think the fallback character depends on whatever fonts you have installed on your systems, like literally whatever is first in alphabetical order or something like that. So it really does look to me like this font is simply missing a true sharp character, instead putting a sharp-looking character where the "#" belongs.
In reply to Since this is just text, I… by Marc Sabatella
Could be, I was under the impression we might do some musical-font-like smarter substitution for those as well, likely we're not :)
In reply to Since this is just text, I… by Marc Sabatella
Ah, I get it now. I will look more closely at the font definitions for my Inkpen2Chords.otf file and see if I can manually paste some accidental signs in the proper places.
In reply to Ah, I get it now. I will… by Al Loast
Did you manage to make it work fully? I used the method you describe but wasn't able to make it work for alterations, which should use superscripts like in:
But I only get:
By the way, even the first example, using MuseJazz Text for chord symbols font and "Jazz" for chord symbols style, looks wrong, compared to:
which is what is displayed in the "Chord Symbol Voicings for Playback" example. I guess this should be addressed using a custom XML file, but I have no clue about how to do it.
In reply to Did you manage to make it… by Pierre-Yves Saumont
ould you describe in more detail what in particular you re trying to do that isn't covered already by just ticking to the defaults in the jazz templates? You should get excellent rendering right out of the box. Or, if you aren't using one of the templates that sets everything up for you, just go to Format / Style / Chord Symbols and set the appearance to "Jazz".
If you are saying you wish to use a non-standard font (one that doesn't adhere to the SMuFL standard for music fonts), that's tougher. But, if you have flats and shapes appearing at all, that's a good sign. Then see the superscripting options in that same dialog at least - separate scaling and offset controls for extensions vs modifiers.
Regarding 6/9 chords, they should display fine t default sizes, but it's true the special handling to make that stacking doesn't deal well if you've scaled things too far up or down.
In reply to ould you describe in more… by Marc Sabatella
I am trying to use Finale Jazz font from Finale 27, which is said to be SMuFL-compliant. "Jazz" style seems to be using only the MuseJazz Text font, whatever is selected for Text Styles / Chord Symbols, so I guess I should use an XML file with the "Custom" option Selected. My first problem was determining which existing file to start with. I found 9 of them: cchords_muse.xml , cchords_rb.xml, chords.xml, stdchords.xml, cchords_nrb.xml, cchords_sym.xml, chords_jazz.xml, chords_std.xml, jazzchords.xml Which one is the most appropriate to copy and modify? My guess is that it should be chords_jazz.xml, since it's what is displayed (alsthough disabled) when selecting "Jazz" for "Chord Symbols". Or does this file rely upon specific characteristics of the MuseJazz Text font?
I made various experiment, trying to understand how it works. First, I created a test score with three chords, "bb6/9", "bb6,9", and "bb69". and selected "Standard" for the style and "Finale Jazz Text" for the font, keeping the default size of 15pt I got this:
Obviously, the size isn't good. Changing the extension scaling doesn't solve the problem. Using a smaller size for the chord font (13pt instead of 15pt) does, but with the drawback that the chord name (Bb) is also reduced:
Then I switched to "Custom". The name for the file "chords_std.xml" was then enabled, and nothing changed. I first thought that this option was equivalent to "Standard", but nope. It seems to be just because the selected file is used only if we change it. Changing to another one and back to chords_std.xml gave this:
Making a copy of the file "chords_jazz.xml" and changing all occurrences of MuseJazz Text into FinaleJazz Text gave this result:
At this point, I wonder how are chords selected. The XML files now has the following (standard form chords_jazz.xml):
<chord>
<name>6/9</name>
<render>m:1:-2 s6 m:-2.5:0 s/ m:-2:7 s9 m:0:-5</render>
</chord>
<chord>
<name>6,9</name>
<render>s6 m:0:-&mod; s, m:0:&mod; s9</render>
</chord>
I thought that this was what allowed bb6/9 and bb6,9 to be recognized, but it seems it isn't the case.
So, my two questions (at this point) are:
How can I have the 6 and the 9 stacked like in Standard mode.
How can I have bb6/9 and bb6,9 recognized as chords (and incidentally, why do they have different definitions in chords_jazz.xml?
(By the way, I have an additional question bout how to represent code in this forum. None of the Markdown options I know seems to work. I represented the above XML snippet using entities, which was the only way I could make it represent brackets, but indentation is lost.)
In reply to I am trying to use Finale… by Pierre-Yves Saumont
Use <XML>...</XML>
In reply to Use <XML>...</XML> by Jojo-Schmitz
Thanks! And what should I use for other kinds of code (that are supposed to be put between triple backquotes in Markdown)?
In reply to <chord> <name>6/9</name>… by Pierre-Yves Saumont
There's also CPP, BASH and a few more such tags
In reply to I am trying to use Finale… by Pierre-Yves Saumont
It's true the "Jazz" style is specifically hard-coded to use MuseJazz Text. If you have an unusual special reason to need to use a third party font instead, but otherwise wish to copy that exact style of rendering, you'd need to customize the XML file, and you'd want to start with chords_jazz.xml indeed. The documentation - such as it is - is within the file.
But it's a lot of work, and really shouldn't be necessary. Are you sure you really need to use that specific font? And if so, are you sure the superscripting controls provided within the dialog itself are not sufficient? You mention scaling doesn't work for you - what goes wrong when you try? Works fine for me. Also, best to attach your actual score instead of just pictures.
The code you should is indeed the code that recognizes 6,9 and 6/9 chords. If you wish to emulate the renderingused in standard mode, look at chords_std.xml for guidance.
In reply to It's true the "Jazz" style… by Marc Sabatella
Are you sure you really need to use that specific font?
Yes, I was asked to use alphabetic characters from Finale Jazz Text for chords, for reasons that are mostly aesthetic preferences, I guess. This is difficult to argue about!
And if so, are you sure the superscripting controls provided within the dialog itself are not sufficient?
Yes. In the bes69 example above, with 15pt size characters, the 6 and the 9 are overlapping. If I reduce the size of the font to 13pt, the 6 and the 9 are OK, but the B is too small. Neither changing "Extension scaling" nor "Modifier scaling" solves the problem.
The code you should is indeed the code that recognizes 6,9 and 6/9 chords.
That's precisely what doesn't work. Neither bes6,9 nor 6/9 seem to be recognized.
The first step would be to have any chord from the Part III section of the chord_jazz.xml file to be recognized.
The second step would be to understand what each element of
<render>m:1:-2 s6 m:-2.5:0 s/ m:-2:7 s9 m:0:-5</render>and
<render>s6 m:0:-&mod; s, m:0:&mod; s9</render>do. But since I can't have them be recognized (meaning adding or removing the chord elements in Part III doesn't change anything), I am stuck.
I enclose a test file and a modified version of chord_jazz.xml, from which only the font selection is working. I can see any interpretation of 6,9 nor 6/9.
In reply to Are you sure you really need… by Pierre-Yves Saumont
I guess if someone is paying you explicitly to use the Finale font, you don't have a choice. But hopefully you are charging them more for all the extra trouble it causes!
Sounds like you are saying superscripting works in general, it's just problematic for 69 chords. Indeed, that special stacking needs to be done differently, and the code in the default XML files is tuned specifically for MuseJazz. So you'd need to adapt that one specifically. I believe you can't define a chord for "69" because MuseScore sees that as a single number, so instead, it's handled farther up in the file, just search on that string to see the "token" definition for it.
The documentation for the format is there in the file, it explains how m: is used to create the offets, and the other aspects of the file. s6 and s9 are defined with "sym" declarations - they are special superscripted versions of the numbers provided by MuseJazz. You'd need to defined your own version for use with other fonts. The documentation isn't very detailed because this is really an advanced customization meant only for for people who don't mind getting their hands dirty with this stuff and experimenting.
In reply to Are you sure you really need… by Pierre-Yves Saumont
But for me, the 6,9 and 6/9 chords are working just fine. If I alter your render statements in the XML file, that shows up in the score upon re-loading the XML file. Well, at least for C6/9. 6,9 doesn't seem to work, I think maybe that chord gets special-cased somehow.
In reply to But for me, the 6,9 and 6/9… by Marc Sabatella
Unfortunately, no one is paying me! But I still need to take into account what people want.
You say it works for you when you alter the render statements and reload the file. Is there a specific way to reload the file? I couldn't find anything besides switching to a different file and the back to the modified one. And by the way, I couldn't figure out what the "Load XML" checkbox is supposed to do. In my case, it does nothing.
Could you please post an image of what you get with the modified file, as well as the changes you made to the file? Just to be sure I am not missing some important step.
In reply to Unfortunately, no one is… by Pierre-Yves Saumont
I don't have that font, so it doesn't look "right"; there would be no point in showing you the gibberish I see.
By re-load, I really mean, create a fresh score and copy your content into it. Unfortunately, with custom chord description files, once you've loaded them, even tricks like switching to another and then back won't completely remove the original render statements. These get "baked in" to the score so that you can share it with others who don't have that same style file on their computer, but that makes it difficult to remove them also.
But if I add some random stuff to the render statements and then use it in a new score, it works fine. Actually for all three chord symbols; I think I got tripped up by the whole "baking in" thing in my previous test.
The "Load XML" checkbox as far as I know is supposed to say "Load chords.xml". This was, way back in the 1.x days, the only way for MuseScore to recognize chords - a separate file with an exhaustive list of the names it would recognize. It hasn't been needed since we implemented an actual parser back in 2.0.
Anyhow, as you can see, it's a lot of work as MsueScore really doesn't support this. If you're not getting paid, hopefully they at least will return the favor somehow. or, you could simply tell them, "sorry, it's not supported, this other handwritten font will have to do".
In reply to I don't have that font, so… by Marc Sabatella
I have managed to use any symbol in the font. But the problem is that the behavior of MuseScore is inconsistent. For example, if I use an XML file with a definition for cm(maj7), it is correctly interpreted. But if I switch to "Standard", or to any other XML file, and even to if I reselect the same file, the chord is replaced with cmmaj7. Of course, when I switch back to my XML file, it no longer works.
Here is an example. I select the xml file, then enter this:
I get the following result:
If I select the same file again (because I have made some changes with no relation to this chord), the chord has then been changed to:
The parentheses have automagically disappeared. But the strangest thing is they are still displayed, although the overall chord layout is incorrect:
Retyping the chord restores the correct layout. This seems pretty much inconsistent. It would not be so difficult to workaround if it was documented, but it doesn't seem to be. Well, now, this specific problem might be considered documented (at least for me!), but there are many others!
In reply to I have managed to use any… by Pierre-Yves Saumont
As usual, in order to assist, we'd need the score and precise steps to reproduce the problem. but probably it's similar to what I said before - once you load a custom XML file into a score, it's kind of "contaminated". So I wouldn't keep using the same score for these tests, just start new scores when you want to try out new versions.
In reply to As usual, in order to assist… by Marc Sabatella
I understand that. I am mostly using a template that I reload as much as necessary. There are several problems involved, so I am trying to isolate them before submitting an example. One of these problems is that the "Load XML" button in the Style/Chord symbols dialog box isn't documented in the Musescore 3 Handbook. My guess is that it means that the XML is loaded in the score in some way in order to allow the score to be shared with other users who don't have the XML file available. It also seems that there is no way back: once the XML has been loaded, there is no reliable way to ensure it is removed or even overridden on the next load.
Another problem is that any change in this dialog box is applied immediately to the score. The "OK" button doesn't seem to do anything other than close the dialog box. This is pretty counterintuitive. Much more common practices are to have an "Apply" button to see the result of a change, or to apply the change only when clicking OK. Of course, seeing each change as soon as it is made is the best option, provided all changes are cancellable, which isn't the case for loading an XML file.
This is even made worse by the fact that there doesn't seem to be a simple way to reload an XML file (after having made changes in an external editor. Reselecting the same file doesn't do anything. The only possibility seems to load a different file and then the modified file again. This is tedious but would be acceptable if not for the risk to pollute the score with the different file. My workaround is to use two copies of the XML file, making modifications in both of them and alternating between them. If you know a simpler way to reload the XML file, it would greatly help. (The best solution would be an "Update XML" button. (Not "Reload XML", since that would mean storing the XML into the score, what you call "contaminating").
Regarding providing a score and the step to reproduce the problem, I will do that as soon as I have isolated a specific problem since I am experiencing several problems at the same time. For example, after having seen parentheses disappear in a chord, I am now seeing parentheses appear in a chord that doesn't have any.
In reply to I understand that. I am… by Pierre-Yves Saumont
None of this is documented indeed. But I did explain the misnamed "load XML" (should be "load chords.xml" earlier. Basically, unless you are using a MuseScore 1.x chord description file, leave it unchecked, it's not relevant.
And yes, it's awkward to reload a file. I can't emphasize enough that this is all experimental, never meant to be supported or used except by other programmers, and will probably go away in a future version.
None of which is meant to say, don't do it - if you have the technical expertise and free time to explore and don't mind the challenge. I'm just trying to set your expectations - this is not something ordinary users would normally be messing with, and it isn't something where you can reasonably expect to see better documentation for, or bugs fixed, etc.
BTW, It's true the style dialog is live. Normally that's a good thing, as it lets you see changes in real time, without the need to hit Apply. This was a long-requested feature that finally became a reality a couple of years ago.
In reply to None of this is documented… by Marc Sabatella
Hello
I am trying to make sense of this. I use the Jazz font and have this problem with the incorrect sharps and flats too. I use a Macbook, so not sure how to fix this. My workaround is to paste onto file that has the correct font showing but that is not a clever way to do things. Anyone?
In reply to Hello I am trying to make… by raymond@rdqa.com
BTW If I start a new score I have this problem, but I paste over a used score as a template, and save it as something else... hat's the workaround.
In reply to BTW If I start a new score I… by raymond@rdqa.com
screenshots