XML Issues

• Jan 25, 2010 - 11:09

Hi,
I'm currently writing a programme to convert the MusicXML exported by MuseScore into PMW code, so I can print customised key signatures, and a few other things. Hence, anything missing in the xml exported code will mean lost effort; I mean, I use MuseScore during the composition / arrangement phase, but for preparing the ultimate, printable version I need to transfer the whole of what I did into PMW for further processing. That's the whole idea of XML in the first place, isn't it?

Now, I noticed the following (so far...):
1) Accidentals, apart from flats and sharps, are never exported. An empty element is there alright, but with no accidental specification.
2) Clef changes appear where cautionary clefs are put, i.e. at the end of the preceding meaure. It appears that the MusicXML specification does not impose any rules here, but wouldn't it be more logical to put the clef change where it starts to be effective, and leave the cautionary clefs for the importing programme to worry about? So, when a measure starts with a new time signature AND a new clef, why is time signature change put at the stat of the concerned measure, but not the clef change? Shouldn't they be contained within the same element at the start of that measure?
3) Although double tremoloes are displayed on screen, they're never exported to XML; only single tremoloes are.
4) Is there a way in the MusicXML specification to distinguish between system text (like tempo changes) and text that applies to the staff that happens to be at the top of the system? So, for example, a "rall." concerns every staff in the system, but a "sempre pizz" on the Vn I staff of a string quartet should only concern the Vn I player, and should not be replicated on other staves when each of them is extraced.

Note: I only posted this after I found nothing about the above points in the Issue Tracker's xml search results.

Many, many thanks.

Hosam Adeeb Nashed

Comments

• Jan 25, 2010 - 20:13

I can count a few things, relly.

1) Key signatures containing half-flats, or even naturals.
2) Right-to-left music, to suit lyrics in Arbic.
3) EPS out for excerpt enclusion in documents.

On another note, although the coming point might not be relevant here: Cautionary clefs are only of any use if the the new system will start in a new clef, so the last measure on the preceding system would warn the player about the coming clef. But what benefit would there be if, within the same system, on the same line, I would see a clef change just before the bar line? It's even smaller in size!!!

Hosam Adeeb Nashed

Reply

• Jan 26, 2010 - 19:41

All I wanted to say, actually, is: MuseScore consistently puts a new clef to the left of the measure where the change should take place; for example in measure three of an 8-measure system. Now, it doesn't really make sense; it should work exactly like time or key changes; i.e. they are written in the measure they start, possibly with a cautionary measure if that starting measure is the first on a new line.

Hosam Adeeb Nashed

Reply

• Jan 26, 2010 - 21:36

In the score the clef change appears before the barline. But in the MusicXML file, clef changes are part of the attributes element, which is generally used at the start of a bar.

MusicXML allows either positioning. In general I think it is better for this type of clef change to go at the start of the bar, rather than the end of the preceding bar. Doing it that way emphasizes the musical structure rather than the typographic layout.

Reply

• Jan 31, 2010 - 18:41

Hi,
I am very glad to hear, that the next version will have the option of non standard (microtonal) key signatures. I must say that microtonal playback would be of great importance - Lilypond can play quarter tones correctly, AFAIK Finale can't play microtones. As contemporary composer I am particularly interested in this feature.
OpenMusic , which is specialised programming environment for composers uses midicent - every half step is divided into 100 steps - so you can use any imaginable tuning. In this system the middle C is 6000, middle C eight-tone higher is 6025, middle C quarter-tone higher is 6050, C# is 6100 etc. In order to get correct microtonal playback it sends pitchbend messages to the midi gear.
Would it be hard to implement this in MS? I haven't got much experience in programming, but if someone could give me some directives I could try to do it.

Reply

• Jan 31, 2010 - 20:21

It is already possible to tune on a note-by-note basis by right-clicking on the notehead and choosing "Note Properties...".
I don't remember if it is in 0.9.5 but the Note Properties dialog for 0.9.6 has a "Tuning offset" where you can adjust the cents.

There is a feature request for playback and proper support for quarter note in the issue tracker. See #3807: Quarter tones are not played

However the focus of the upcoming 0.9.6 release has been to get regular sharps/flats/naturals working correctly and transposing without issues.

Reply

• Feb 8, 2010 - 17:32

Hi lasconic,
I was trying to adapt a utility I had written long ago to be used as a plug-in, following your example, but so far it refused to even show within MuseScore... Obviously, I'm doing something completely wrong. Could you please take a look. Don't pay attention to the various buttons, I'll fill their functionality in once the thing takes shape.

Thank you very much in advance.

Attachment Size
MScorePlugin.zip 3.93 KB

Reply

• Feb 9, 2010 - 05:12

Probably it is best to start a new thread for the plugin. When I try to use your plugin using 0.9.6 beta I get the error as quoted below. In the new thread mention whether this is what you mean by "refused to even show within MuseScore".

---------------------------
MuseScore Error
---------------------------
Error loading plugin
"C:/Program Files/MuseScore 0.9/plugins" line 62:
TypeError: Result of expression 'form.allButtons' [undefined] is not an object.
---------------------------
OK
---------------------------

Reply

• Jan 25, 2010 - 21:44

1/ MusicXML supports the following for alteration : sharp, flat, natural, double-sharp, sharp-sharp, flat-flat, natural-sharp, natural-flat, quarter-flat, quarter-sharp, three-quarters-flat, and three-quarters-sharp. If I understood well the discussions about quarter tones music, it's not really define which symbols is a quarter sharp. Am I wrong?
2/ Bug report filed : #4226: [MusicXML] Clef change export on the wrong measure

Short Instrument name is exported at part-abbreviation in r2644

Reply

• Jan 27, 2010 - 18:06

They are all already supported by MuseScore. The only one that differs than most music notation software is the quarter-flat: whereas Finale, Sibelius and the rest use only the mirrored flat, we use a normal flat with a stroke in its stem. So, the two should actually be considered alternatives.

As used in Egypt, they are the following:

  • quarter-flat: a flat with a slanted stroke
  • three-quarter-flat: two flats with one elongated slanted stroke
  • quarter-sharp: one vertical line with two slanted strokes
  • three-quarter-sharp: three parallel lines with two slated strokes

Hosam Adeeb Nashed

Reply

• Jan 28, 2010 - 00:16

In r. 2649 "flat-slash" and flat-flat-slash" should export to quarter-flat and three-quarter-flat respectively. Obviously this means there is some loss of information (software importing file won't know whether the quarter flats are supposed to be displayed as a mirror flat or a slash flat). If future versions of MusicXML improve micro-tonal support we can review this decision.

Reply

• Jan 26, 2010 - 07:25

Hi Michael,

Off topic: I got a question from someone who wanted to create MusicXML from Braeburn score files. To my knowledge, MusicXML is not supported by their software and pdf files created with the software can not be scanned with pdftomusic, nor with photoscore. So you happen to have an idea how to convert them to MusicXML?

Reply

• Jan 26, 2010 - 07:45

As far as I know, you're correct that Braeburn does not support MusicXML, either for export or import. I'm surprised that the PDFs do not work, but that can happen due to things like not using music fonts, or blocking embedding of music fonts. Music Printer Plus and Score have problem with printing usable PDFs as well.

If the PDFs don't work, then it's back to either optical scanning or MIDI transfer.

Michael

Reply

• Jan 26, 2010 - 18:40

Please be sure to add the alter element as well as the accidental element - for instance, 0.5 for quarter-sharp, 1.5 for three-quarters-sharp, -0.5 for quarter-flat, and -1.5 for three-quarters-flat. Please let me know if that still does not work for import into Finale (I don't know if Sibelius supports this during import).

Michael

Reply

• Jan 26, 2010 - 06:50

Hi Hosam,

If you wish to give your converter some publicity in the future, make sure you can deploy it as a web service. As an example: On Google App Engine you can deploy java & python software which you can interface with MuseScore via a plugin. See Lasconic's ABC importer plugin for inspiration.

Reply

• Jan 26, 2010 - 20:13

As a matter of fact, the programme started life as a JavaScript application, then, when I felt it was becoming quite heavy, I shifted to my preferred language of old: Pascal. I could potentially re-write it in Python; I always wanted to learn Python nyway. But I'll just leave that to later, when I finish the essential parts.

My original plan was to send the programme (in source and binary forms) to Dr Philip Hazel, the author of PMW, to distribute it with a new release. Of course, once it covers most of my set goals (I'm almost half-way).

Hosam Adeeb Nashed

Reply

• Jan 28, 2010 - 07:40

Single tremolo is rapid repetition of one note, double tremolo is rapid alternation between two notes. MuseScore does support writing them alright, but it doesn't play them, or export them to XML.

Hosam Adeeb Nashed

Reply

• Feb 12, 2010 - 04:04

I notice that only 3 beams are available to tremolos. It is fairly common for me to see a fourth flag, expecially in a slower tempo. This is needed because a tremolo is a shorthand marking for a repeated group of 1 or 2 notes, rather than just a rapid alternation at an arbitrary speed. I've seen it get so specific as to write a tremolo with a number under it to indicate a tremolo-tuplet.

Reply

• Feb 12, 2010 - 04:52

Maybe it's just a piano thing, but that's where I see tremolos most. For a common example look at Beethoven's Sonata Pathetique where the bass line is eighth notes alternating octaves. Instead of writing out all the eighth notes, he (or at least the publisher) uses in many places a tremolo with half notes and one beam. I also have a reduction to two pianos by Percy Grainger of Grieg's Piano concerto in A minor in which in one measure, Grieg writes a tremolo (trill with a chord) using dotted half notes, 2 beams, and the places the number 12 to indicate the number of alternations. Percy Grainger rewrites the same measure adding "molto ritardando", and doubling the speed of the tremolo by using two groups of dotted quarter notes, 3 beams and the 12. The next beat accelerates the trill, by using quarter notes and 4 beams.
I wish I could show you the printed example that's right in front of me.

Reply

• Feb 12, 2010 - 05:17

Gershwin's Rhapsody in Blue where a chord is repeated rapidly 9 times staccato. 3 dotted eighth notes are beamed together with each having a extra tremolo beam through their stems. 3 staccato dots and the number 3 appear above each one, making it clear that each note represents a 1/16th note triplet group. I'm sure with a little digging I could come up with more examples, but my point is that this doesn't seem to be a wholely uncommon practice confined to a single style or composer.

Reply

• Jan 28, 2010 - 07:39

I noticed that the "credits" (title, subtitle, composer and poet) are exported to XML in their chronological order of creation, rather than in their hierarchical relation to each other. So, if you forget to put a subtitle, and you later put one after you have already inserted the composer, for example, the XML will be exported in that order. It can make it difficult for XMl importers... Not impossible, but a bit more complicated.

Hosam Adeeb Nashed

Reply

• Jan 28, 2010 - 08:32

When the displayed score ends with a clef change, the next staff has a redundant xml clef element. That is, the right-most measure on the previous system will have a clef element, and the left-most one on the next system will have one, too. I suspect the extra clef change could be troublesome.

Hosam Adeeb Nashed

Reply

• Jan 30, 2010 - 10:06

Customarily, staves linked with a bracket also have their bar lines continuous (non-broken), except for the four staves of a choir, to accommodate for lyrics, and avoid any possibility of lines covering them.

Now, this is not reflected in the exported XML, while the standard does cater for that sort of thing: "<group-barline>no</group-barline>".

Also, breath marks are not exported to XML. And if one needs to put two articulations on the same note, e.g. staccato + tenuto (to be played three-quarters of the note head normal time), only one articulation is exported.

Hosam Adeeb Nashed

Reply

• Feb 9, 2010 - 19:12

Hosam,

thanks for reporting these issues. This thread is getting very long and contains several related but different subjects. Could you use new threads for new issues instead of adding to this thread. That will make it easier to keep track of which issues still need to be fixed.

It would be even better if yuo could create new issues in the issue tracker.

Regards, Leon.

Reply

• Jan 30, 2010 - 09:43

I put an "Allegro" tempo direction on the first measure. To my surprise, the XML stated that its placement was "below", rather than "above" the staff!! (Version 0.9.5) In addition, there was an empty element right after it. The other dircections were all right, though. I have no idea what went wrong.

Also, the same thing happened with crescendo and diminuendo wedges; their placement was "above", the opposite of how they were displayed in the score.

Hosam Adeeb Nashed

Reply

• Jan 31, 2010 - 21:18

Yes, I know about manual tuning in MS, but it's not a solution. Would it be possible to define quarter tone accidentals, the same way as normal ones, so everytime you use it in your score it play microtones, as normal notes ?

Reply

• Feb 5, 2010 - 14:10

Hi,
Still working with 0.9.5, I noticed the following:
1) One-bar repeats and double-coda are not exported.
2) There is no clear way of marking things like rit., rall., accel., etc. as system text, in the sense that, unlike tempo markings, e.g. Allegro, they have no "sound" element. They are represented as just "direction" elements that have "words" child elements. But, since their effect should concern all staves within the same system, they need to be marked in a way as to distinguish them from, say, pizz.

Hosam Adeeb Nashed

Reply

• Feb 7, 2010 - 23:05

Still working with 0.9.5.
8va marks, though they seem to end within the same measure (I couldn't extend them beyond that...) are exported in MusicXML as ending at the start of the following measure, instead. Lines' ends are inconsistent, too. Plus, one and the same line segment has its placement as "above" at its start, but, oddly enought, as "below" at its end!

But, apart from the way things are exported to XML, I'm at a loss as to how to tell, within the context of a grand staff, whether an 8va belongs to one of the two staves but not the other. Let me explain: in contrast to Ped, which logically belongs to the lower staff, an 8va alta or bassa might conceivably be used on either staff, or at least I'm unaware of any hard and fast rules. So, on importing them, where should they be put? Always on the upper staff? What??!! [A reminder: the source of the trouble is that the contents of both staves are supplied within the self same measure, separated by a "backup". Hence, the end of a measure only comes after the contents of lower staff. Maybe, if all things that concern the upper staff are put before that "backup", thing would have been easier...]

Any ideas are sorely needed.

Hosam Adeeb Nashed

Reply

• Feb 8, 2010 - 10:28

This morning, while trying to import some other stuff from MusicXML, I discovered the following (I'm not sure they are already known issues; the Issue Tracker didn't help me much):

1) Grace notes are exported using "backup" elements, while the standard offers a much clearer way: a "grace" element, which has a "slash" attribute that is missing from the current implementation.
2) Glissandi are not exported at all.
3) I'm not sure of this one, but in the case of arpegiated chords, why should every note in the chord have an "arpegiate" element? Staccato, for example, doesn't behave like this. In both cases the mark applies to the chord in its entirety.
4) Ottava marks are indeed extensible (me culpa for my inability to do it in my last post), still, it always goes one step beyond the last note it should apply to; so, if it should end at the last note within a given measure, it really ends at the start of the following measure.

Hosam Adeeb Nashed

Reply

• Feb 8, 2010 - 17:20

The arpeggiate element works different than other elements like staccato because, on a score, you visually see an arpeggiate element in front of different notes. The arpeggiate element also needs to be able to handle arpeggios that cross staves and voices.

Reply

Do you still have an unanswered question? Please log in first to post your question.