Kind text from MusicXML not shown if kind definition "other" is used

• Oct 21, 2015 - 00:18
Type
Functional
Severity
S4 - Minor
Status
closed
Project
MuseScore

If "other" is used to assign undefined chord symbols the text="content" should be shown, instead it shows "other"
In order to show a often used chord symbol addition like "7alt".the kind syntax shows this:
{syntaxhighlighter SPEC}
other
{/syntaxhighlighter}
The result shown in W10 a picture from MuseScore 2.0.2 with in 6 red marked arrows (Estate W10 6x7alt.png) lead to the addition "other", but should show "7alt" like in MuseScore 1.3, and in Sibelius and in Finale.
See Estate MS 1.3-6x7alt.png. for the correct representation.
(Remark: MuseScore 2.0.2 in XP shows other as o ther where o is shown as "dim" symbol)

Attachment Size
ESTATE7alt.xml 96.55 KB

Comments

• Oct 21, 2015 - 02:04

I see something with the attachments went wonky, but you don't have to create 5 of the same bug reports to solve it. You can re-upload newer attachments to the same bug report. The PNG files never attached properly, even to this one. I've closed the other duplicate reports.

Reply

• Oct 21, 2015 - 16:24

FWIW, this isn't really good MusicXML: the kind should really have been set to "dominant", because that is what a 7alt chord is.

However, it is true we should honor kind text for "other", so I will make a fix.

I also see that we seem to not be interpreting kind of half-diminished correctly when kind text is explicitly set to empty - measure 13, for example, shows Em7b57 - so I will look at that too. This also is not really correct MusicXML - the text should either contain "m7b5" or maybe some representation of the half-diminished symbol (although there is use-symbols for that). An empty kind text should probably have resulted in just "E", which isn't what was intended but would be a correct interpretation of the incorrect MusicXML. However, we do the same thing on no kind text at all, and that definitely is not correct on our part.

Reply

• Oct 21, 2015 - 16:54
Status (old) active ⇒ patch (ready to commit)

https://github.com/musescore/MuseScore/pull/2264

This PR fixes both of these two cases:

1) kind=other, non-null text (eg, the "7alt" chord)
2) kind=half-diminished, null text, no use-symbols (eg, the "m7b5" chord)

I remain convinced that it is not correct to include a representation of alternate bass note in the kind text, so what you were originally perceiving as a bug in 2.0 is actually correct behavior. However, if you know of other cases where you are currently seeing problems, please file separate bug reports for them, and I can look at incorporating fixes for those in this PR as well. If in doubt over whether the MusicXML is correct or not, maybe best to post to support forum first.

Reply

• Oct 21, 2015 - 20:29

Normally PDFtoMusic repeats in text the kind definitions. It caused only a problem with the bass note. For this example I changed all text into null ("") except the "7alt" which was defined as "other".

You said that "7alt" should be written as dominant, but how do you add the "alt" in that case?
If you write it as:
{syntaxhighlighter SPEC}
dominant or as dominant?
{/syntaxhighlighter}
In both cases it won't show "7alt". The only option is using "other" Valid for all programs MS1.3,
Sibelius and Finale.

When I added the "m7b5" in text to the kind half-diminished is detected correctly. That's why I overlooked it anyway. Strange.

About the bass note added in text I will email with PDFtoMusic and hear what they think about it.
Untill now I had never a problem with it since MuseScore 1.3 and Sibelius do produce correct results.

Can I already download an improved MuseScore version?

Reply

• Oct 21, 2015 - 21:14

It should be kind=dominant, text="7alt". However, you are right - this does not seem to work currently, not sure why - will look into that later.

The basic issue is that 1.3 was pretty stupid and would accept any text presented even though it could not be parsed. So you ended up[ with a "fake" chord - it looked right but would not transpose or export correctly, nor would it necessarily render correctly with flat signs and superscripting as appropriate. 2.0.2 is *much* smarter and can parse almost any reasonable text, but if the text is in conflict with the semantics (eg, the kind says minor, but the text says "Maj"), then this is a problem you need to correct in the input. Somehow I guess the "7alt" is failed the parsing, but I'm not sure why.

Ideally the degrees themselves should be added as individual degree tags - the b9, #9, b5, and #5 - but chances are good that would just import as a mess, so I wouldn't bother including the degree tags.

Right now you see the status of this issue listed as "patch". When it changes to "fixed" (and you should receive notification about that), that will mean the next nightly build will contain that fix. but be aware nightly builds are for experimentation and testing only - they should not be used for real work, as there is no guarantee scores created with any given nightly build will still be openable correctly in future builds.

Reply

• Oct 22, 2015 - 00:30

Sorry but I think you are not correct. Using kind dominant and text="7alt" won't function in any program. Not in Sibelius nor in Finale. So that's defenitely not the way to go. Secondly if you use "other" and "7alt" and open it in Sibelius or in 1.3 both programs will show to you as 7alt but warn you it is a not reguarly known chord symbol from their data base. Sibelius by showing it in red and 1.3 by showing it in smaller characters. In both programs you just click the chord twice and it will change into an by both the programs accepted chord symbol. Save them as resp. .sib and .mscz and it will behave like any other chord symbol. It will show as "7alt" when you open it in the MS Songbook or MuseScore and it will transpose. This is valid for every not (yet) recognized chord. If you save the files as new xml files they both will add b9, #9, b5 and #9. Which you reopen the new .xml it won't show up as alt but with all the added degrees. In other words you shouldn't overwrite the original .xml. I had a discussion with Michael Good specific about the "alt" chord to add it in MusicXML but since it is a kind of undefined chord from which the choices are left to the interpreter, he didn't become very enthausiast. It is used many times in jazz. Just keep it as it was in 1.3.

There is one thing about this chord I don't like that is you need to double click it to accept it in the file. For batch conversion this means you need to check all files for it. Additonally I don't actually understand why as well Sibelius as 1.3 save it as "7alt" in their own format and with all added degrees in xml. Not very consistent. Alt should stay alt and be accepted right away.

Reply

• Oct 22, 2015 - 01:33

Just because Finale or Sibelius doesn't accept something doesn't mean it isn't the best way pf representing it. A "7alt" chord *is* a dominant seventh chord, there can not possibly be disagreement about that. So I don't see any basius for claiming that it *should* use any kind other than dominant. If some programs choke on that, those are bugs that, likes ours, should be fixed. I think the problem is really what you say - "alt" is ill-defined, so every program just sort of makes up its own rules. I will definitely make it so it works with kind of other, but that's definitely not what well-constructed MusicXML files should do. it's a dominant seventh, so the MusicXML should have domiannt as the kind.

The fix I made above already makes it work with kind other with no special double clicking or save/restore to make it work. I just need to figure out why it doesn't work the way it should with kind dominant.

Reply

• Oct 22, 2015 - 08:06

I can agree with your point of view, but I'm just tryïng to figure out what the best solution is to suit the most important notation programs. As long as the interpretation of MusicXML seems to be different for all involved parties it will always leads to cripple conversions. I'm not the one with the authority to say how it should be interpreted I can only figure how to adapt to the majority in order to create the best conversion process for myself that runs smoothly. In any case I always need a filter in the middle which adapts for different interpretations of MusicXML, PDFtoMusic and cripple detections to correct as many things as possible that go wrong.

So I'm very glad to hear that clicking the chord to except it isn't necessary in the future.
I still use 1.3 for batch processing since I didn't yet figure out how to use that with 2.0.2.
I don't yet like the idea of using command lines to do it as has been suggested.

Processes I like to manage are BiaB to .mscz and .sib to .mscz.

Reply

• Oct 22, 2015 - 15:32

Yes. The unfortunate thing is that the msot strictly correct representation of this chord is not actually accepted currently by any of the major programs, apparently.

The reason is isn't accept in MuseScore is that we do a check to be sure the kind text parses to what the kind itself says it should. To prevent kind=minor but text=Maj, for example (by choosing to ignore the text in those cases). In this case, we parse the "7alt" and see that it does generate a kind of dominant but also adds a bunch of degree elements that are not present in the original, so we end up rejecting it on that basis. Suggesting that *really*, the correct representation is something more like a kind of dominant with no text, then four degree tags, the first of which has a text of "alt" and the others have empty text.

But truth be told, that won't work in MuseScore either, because we don't pay attention to text on degree tags. We always generate the text for those ourselves. So if you did include all thsoe degree tags, you'd get explicit b9, #9, etc in your chord symbol.

I canadd special casing for "alt" in the kind text so we don't give up on it just because it generates spurious degree elements. There will doubtless still be other cases where something you'd want to work won't, but this *is* probably the most common cases to be concerned about.

Reply