MusicXML - control of note play timing
In another thread on this topic, readers were treated to the spectacle of my making a dramatic change in what I believe is the "underlying intent" of the MusicXML specification as to the reaction of a program receiving a MusicXML file to the element duration and the attributes attack and release.
The information in the MusicXML documentation is sufficiently "coy" in this that I can't be fully confident that my interpretation is "right", and of course I am not clear on how we should define "right".
I made some admittedly-quick tests to probe the behavior in this area of four prominent notation programs: Overture, MuseScore, Finale, and Dorico SE ("Dorico Lite"). Testing only involved files in which the element type (directly tells "quarter", "half", etc.) is always included.
The questions asked were:
• Upon import of a MusicXML file, how does the program respond to the element duration and the attributes attack and release?
• When exporting a MusicXML program, how does the program encode information on the start and end play times (or, if you wish, start play time and play duration?
Simplistically, here are my findings:
Overture - Incoming, responds to the element duration to control the note play duration. Outgoing, encodes the note play duration into the element duration. No response to or use of the attributes attack and release.
This works nicely in Overture-Overture communication via MusicXML (not useful in any real situation). It does not comport with my current interpretation of the MusicXML specification. (I may have in part been responsible for Overture working this way!)
MuseScore - Incoming, responds to the element duration to set the musical time allocated to the note. Makes the note play duration the theoretical duration of the note type involved. No response to or use of the attributes attack and release. Outgoing: nothing.
The incoming behavior is partly consistent with my interpretation. A difference is in play duration. MuseScore makes it the "face value" of the note, but in my interpretation, it would be the musical time allotted to the notes (and thus the value of duration). But I am not fully confident that my interpretation in that specific detail is "right", whatever that might mean.
Finale - nothing either way.
Dorico SE - nothing either way.
More on this later. I have to get dressed for Thanksgiving dinner (just Carla and myself, at home).
Happy Thanksgiving, all.
Doug
Comments
An outrageous proposal
So what would be "intellectually attractive" to make possible the general exchange of note play time information via MusicXML? Well:
• There would need to be "general agreement" as to the way the syntax would be interpreted.
• Each of the "participating" publishers of notation and related programs would implement this scheme in their product(s).
And while I'm at it. I might just as well wish to have world peace, eradication of hunger, and stopping global warming. Because those are about equally likely to happen.
Another approach would be outrageous to those of us who believe in technical standardization. Somebody would contrive an alternate syntactic schema for this matter, not really fitting the various clauses in the MusicXML documentation that, through a glass very darkly, serve to describe "the real deal",
Then, a couple of key players would make provisions to accommodate this in their programs' MusicXML handlers, perhaps in a way that the "real deal" (whatever that is) would not be completely discarded.
This "alternate syntax" would not support all the things that the "real deal" could do (but never really happen). For example, perhaps it would support in its basic modus operandi description of note play durations but not variations in note start time. And perhaps it might not, in its basic modus operandi, support the direct encoding of notes inégales.
Now, various scorists might say, "But I need control of play start times when I send a score from Salieri to Fidelio", or "I need encoding of notes inégales for swung eighths style when I send a score to my publisher." I understand. But today you have basically nothing in this whole area - nothing. Except that we can send a score including variations in note play duration from Overture to Overture via MusicXML, why ever we would want to do that.
What might such a "lowest common denominator" syntax look like? Well, perhaps it would declare that the element duration describes the play duration of the note - period. That's the whole thing.
Now this might look like a baldfaced attempt to make the existing Overture syntax for note play times work into and out of MuseScore. Hmm.
So what could then be said of MuseScore's MusicXML capability? That it "conforms with the MusicXML specification". 'Fraid not. Can we honestly say that of MuseScore today? Well, probably not.
After turkey my blood glucose level will be higher and I can perhaps think more clearly about this.
Later.
Best regards,
Doug
In reply to An outrageous proposal So… by Doug Kerr
For clarification, I will describe here the "apparent intent" of the MusicXML syntax regarding play durations and the like that I have crafted. Note that this involved a lot of "triangulation" among various statements in the documentation. I make no representation that this is the actual intent (if there really is one).
This is all from the viewpoint of how a program receiving a MusicXML file would react to the various indications.
I will assume that each note element includes a type element.
• The notational duration of the note (e.g., quarter, half, etc.) (also known as its "time value") is as given by the value of the type element.
• The allotment of musical time to the note is as given by the duration element.
• The basic performance (play) of the note is over its musical time allotment. Thus its performance duration is the same as given by the duration element.
• If present, the attack attribute of the note element dictates how the performance start time varies from that suggested by the musical time allotment.
• If present, the release attribute of the note element dictates how the performance end time varies from that suggested by the musical time allotment.
For comparison, it appears that, again in the context of response to a received MusicXML file, current MuseScore does the following. Departures from the above schema are in bold,
• The notational duration of the note (e.g., quarter, half, etc.) is as given by the value of the type element.
• The allotment of musical time to the note is as given by the duration element.
• The basic performance (play) of the note is over the span suggested by its notational duration. Thus its performance duration is the same as given by the type element. (In some contexts we would say "play is at 100% of face value.")
• There is no effect of, if present, the attack or release attributes of the note element.
Best regards,
Doug
In reply to For clarification, I will… by Doug Kerr
Suppose it were concluded here that my interpretation of the "intent" of the MusicXML protocol was "appropriate", and MuseScore's behavior were modified to conform to it. How then would Overture deal with a MusicXML file emitted by today's version of Overture?
There, the type element is used to convey the notational duration of the note, it is assumed that the musical time allotted to the note matched its notational duration, and the duration element gives the play duration of the notes (it being assumed that the start of play would be at the start of the musical time allotment).
Now suppose we had an Overture MusicXML file for a score comprising a series of quarter notes, all intended to sound for 90% of "face time". Then for each note type would be "quarter" and the value of duration would be 90% of the theoretical time for a quarter note,
What than would the postulated modified MuseScore make of this? The notation would show four quarter note symbols. The beginnings of the "musical time era" for the notes would come at intervals of 90% of the theoretical time for a quarter note; thus the pace of play would be faster than for a series of quarter notes. Each note would sound for 90% of the theoretical duration of a quarter note; the sounded notes would "abut" in time (there being no gaps between them).
And likely MuseScore, if its MusicXML validation engine worked as at present, would complain that the MusicXML file was corrupt: there was not enough accumulated "duration" to fill the measure.
Now. let's do that same exercise with the current behavior of MuseScore. The MusicXML setup is as before.
The notation would show four quarter note symbols. The beginnings of the "musical time era" for the notes would come at intervals of 90% of the theoretical time for a quarter note; thus the pace of play would be faster than for a series of quarter notes. Each note would sound for the entire theoretical duration of a quarter note; the sounded noted would overlap in time.
And the MuseScore MusicXML validation engine would complain that there was not enough accumulated "duration" to fill the measure.
By these exercises I do not in any way mean to suggest that the MusicXML file generated by Overture was "correct" (whatever that would mean).
Doug
In reply to Suppose it were concluded… by Doug Kerr
To be sure than another aspect of MuseScore's behavior in this area does not get lost, I point out that, for a MuseScore score comprising a series of quarter notes, all set for play to start at the normal time and for the play duration to be 75% of the theoretical time for a quarter note, In the MusicXML file that MuseScore would generate, for every note type was "quarter" and the duration element carried the theoretical length of a quarter note. There were no attack nor release attributes.
That is, no account was taken in the MusicXML file of the play durations of the notes carried in the score.
Doug
In reply to To be sure than another… by Doug Kerr
What is the advantage of defining the significance of the duration element as telling the musical time allotment for the note (and then only by inference giving the basic play duration)? For one thing, it allows the direct encoding of notes inégales, of which a very common example is swung eighth notes.
The price we pay for that ability is that the duration element can no longer be used to dictate the play duration of notes in "normal" rhythmic situations.
But allowing that (and some other things) to be done is presumably the task of the attributes attack and release.
So to be able to do a lot of things, we need a lot of tools. And sometimes, that makes doing "ordinary" things complicated. And if we want to learn to speak French, we probably can't avoid finding out about past participles. And probably the subjunctive mood. "Si j'etai roi", n'est-ce pas?
So suppose MuseScore gets the ability to precisely speak and perfectly read French, at least about note durations. With whom can it speak? Nobody that I know of.
Doug
In reply to What is the advantage of… by Doug Kerr
So, I have read through most of the posts in these two threads. I have a few observations and maybe, questions.
As I understand it, the purpose of the musicxml is to accurately (or exactly ?) transfer playback information between (notation) platforms. At least as presented in these threads. The problem I see is that playback is not the primary goal of notation software. At the simplest level, each software handles playback differently. In one software, based on the sound library and playback engine, it might make sense to set note durations at a certain amount. But in different software, those settings might not be appropriate.
When I transfer files back and forth between MuseScore and Sibelius, I can't think of a time when the scores looked or sounded the same. Nor is that the point for me. Besides, I do so many things to a score to get the playback that I want that it might hardly be readable in other software. Or at the very least, impractical. I realize that not everyone does this, but for me the xml is only a starting point. Sibelius, 35 GB library. MuseScore, less than 100 MB GM font.
I can see that if I were importing from MuseScore into a DAW, all this would be more important. Or even from a DAW into MuseScore. Although at the moment DAW files in notation are a disaster. It may be interesting to see what happens when MS includes a DAW. I understand that MS will be able to use VSTs, but good ones are not free.
Or have I missed the point altogether?
In reply to So, I have read through most… by bobjp
Hi, bob,
Thanks for your thoughts on this.
Doug
In reply to Hi, bob, Thanks for your… by Doug Kerr
Hi, bob,
Here is the matter that concerns me. Imagine a scorist who formerly did most of his work in Overture, but now uses MuseScore for most of his work. He has a large library of scores in Overture, some of which he wishes to transfer to MuseScore for further work, or just to be played as is for some reason. (Perhaps he is a music teacher, and some of these works are tutorials, and they will be played, by MuseScore, in the course of lesson sessions.)
Imagine some of those works in which subtleties of note play durations are not important, and in the Overture score, they all carry play durations of 90% of face value, Overture's "factory default" for that property when notes are, say, deposited by mouse. This leads to a pleasant enough sound for the type of work we imagine when played (in Overture).
Now he transfers this score into MuseScore via a MusicXML file. At first it seems that the transferred score, after perhaps some adjustment of text items, is "ready to play".
But the combination of Overture's outlook on the meaning of the MusicXML encoding of note play durations and MuseScore's outlook on the same thing means that, for example, in a measure containing four quarter notes, the onset times of the notes as sounded are separated not by quarter notes' worth of musical time but rather by intervals only 90% that long. The four quarter notes are slightly "rushed" (not just "shorter than intended" in play duration, but rather coming along faster than intended). And MuseScore adopts a peculiar measure length, in terms of musical time, to accommodate this curiosity.
Incidentally, current MuseScore, faced with this score, although sounding the notes "too fast", sounds all the notes for "100% of face value".
It is this reality that concerns me.
Best regards,
Doug
In reply to Hi, bob, Here is the matter… by Doug Kerr
The attached MusicXML test score file, Duration_test-2070.musicxml, will serve to illustrate this matter. As is my wont,. it is musically impractical, being contrived to illuminate the phenomenon being discussed.
It is useful to load this into MuseScore and then examine its entrails with the Piano Roll Editor. When you attempt to load it, you will receive an error message to the effect that the file is corrupted. Just click on "Ignore" and proceed.
This work uses two voices, It consists of simple repeated patterns of quarter notes in both voices. The notes in voice 1 (the lower ones) have values of the duration element of 90% of the theoretical time of a quarter note. The notes in voice 2 (the upper ones) have duration at 75% of the theoretical time of a quarter note. These MusicXML encodings came from the fact that the original score, in Overture, had those note play durations assigned (en masse, for each voice).
If you look at the play picture in the MuseScore PRE, you will see that in the two voices the notes as sounded occur at different rates. The voice 2 notes come along faster than the voice 1 notes, and then have a hiatus at the end of each measure. Overture has set the measure length, in musical time, to 3.6 beats, to accommodate the four quarter notes with duration at 90% (which lead to the longest accumulated musical time per measure).
Note that all notes are sounded for 100% of the note face time.
Even to a scorist who is sanguine about the matter of note play times, the result here is hardly "usable".
By this do I mean to declare that Overture's outlook on the encoding of note play durations is "correct"? There is no "correct". But it follows, as far as it goes, the protocol I suggest we consider adopting as "desirable".
Best regards,
Doug
In reply to The attached MusicXML test… by Doug Kerr
For further thought.
Sibelius will not open your test score. Nor will it open the same format from MuseScore. It will open an mxl format from MuseScore but with layout errors. Sibelius labels it an old format. Playback seems to be OK.
What happens if you change the Overture default note length to 100%? If I remember correctly, note duration settings in Sibelius affect playback and wav. export only. Not other export formats.
Perhaps MuseScore will change. Or not. In the meantime, I am not at all surprised that there are format problems. The oft repeated saying around my house is "they ought to standardize these things."
In reply to For further thought… by bobjp
bon,
Thanks for those reports.
If in Overture we select the whole score and set all the note play durations to 100% (which is labeled in a strange way in Overture, the resulting MusicXML score is loaded by MuseScore without complaint and produces a quite sensible score.
The attached file, Duration_test-2071.ovex, is that way.
This is in fact what I generally do to prepare an Overture score for transport to MuseScore.
As to, "The oft repeated saying around my house is 'they ought to standardize these things.' ": indeed.
Thanks.
Doug
In reply to bon, Thanks for those… by Doug Kerr
With regard to the -2070 test file:
Finale (26.3.1) loads the file without complaint and produces a score with only the voice 1 voices - I am not familiar whit that program, and may have had something set inappropriately so that the voice 2 notes did not show up.. All voice 1 notes have their play onset at the "normal" times (that is, the musical time allotments are "normal") and have play durations of 100% of face. It has been known that Finale ignores the duration element (unless the type element is missing, in which case Finale deduces the time value of the note from duration).
Dorico SE (3.5.11) loads the file without complaint and produces a score with the expected notation for all notes. All notes have their play onset at the "normal" times (that is, the musical time allotments are "normal") and have play durations of 100% of face.
Doug
In reply to With regard to the -2070… by Doug Kerr
Sibelius 7.1.3-77 (I only have the trial-expired trial version) will not load MusicXML files with the musicxml filetype extension, only if the extension is xml.
On copies of my MusicXML test files with extension xml, Sibelius loads them gladly.
It is difficult to be sure owing to limitations on the trial-expired version of Sibelius, but it seems quite likely that from a variant of my -2070 test file, Sibelius makes all the play durations 100% of face; that is, it probably ignores the duration elements.
Doug
In reply to It is difficult to be sure… by Doug Kerr
A recommendation
I recommend that MuseScore be arranged to respond to various indications in an incoming MusicXML file thus:
Syntax and protocol - incoming
If for a note there is no type element:
• Deduce the notational duration of the note from the value of duration.
• Make the musical time allotment that implied by the notational duration.
• Make the play start time at the beginning of the note's musical time allotment; make the play duration equal to the notational duration.
Comment: Not very subtle? Hey, people should put in a type element.
If for a note there is a type element:
• Make the notational duration of the note per the value of type.
• Make the musical time allotment that implied by the notational duration.
• Make the "base" play start time at the beginning of the note's musical time allotment; make the play duration per the value of duration.
• If there is an attack attribute, offset the start of the play by that amount; keep the play duration as described above.
• Ignore any release attribute. Comment: it is redundant, and an indication given by it might conflict with the joint implications of duration and attack, what engineers call "overspecification".
Syntax and protocol - outgoing
With regard to an outgoing MusicXML file, MuseScore should encode the note information consistent with the above.
Intercommunication implications
Q. If MuseScore were to follow the above, from which other notation programs known to the author (and I don't get out much) will MuseScore be able, from an incoming MusicXML file, to reconstruct notes with their play timing in the source score:
A. Overture (and that would not include any offset of the start play time from "normal").
Q. What different protocol would allow MuseScore to be able to reconstruct notes with their original play timing from other notation programs?
A. None known to the author.
Q. If MuseScore were to follow the above, to which other notation programs known to the author will MuseScore be able to convey, in a incoming MusicXML file, information that will cause the other program to reconstruct notes with their play timing in the MuseScore score:
A. Overture (and that would not include any offset of the start play time from "normal").
Q. What different protocol would allow MuseScore to be able to cause more notation programs to reconstruct the play timing in the MuseScore score?
A. None known to the author.
Q. Would it be worth changing how MuseScore handles these things just so it could commune (albeit imperfectly) with Overture?
A. Beats me. But I would enjoy it. And I'll bet scorster would too.
Doug
In reply to A recommendation I recommend… by Doug Kerr
I guess what I'm missing here is just how much control an xml file has over playback. Or even if it should have that much. In Sibelius, I have playback of note lengths set in the playback dictionary. Un-slurred at 100% and slurred at 105%. Doesn't make any difference what the source says. I don't know if my preferences are included in any xml I create. Since playback varies so radically from platform to platform (as well as system to system, meaning like car or computer speakers, or headphones) it seems best to me to aim the xml at the target platform. This used to be a time honored process in the recording world.
In reply to I guess what I'm missing… by bobjp
Hi bob,
Well, how much control is a MusicXML file has depends on the behavior of the two communicating applications.
For example: A MusicXML file into Overture can (if this is encoded into the file) control the play durations of the notes. A MusicXML file into Finale can't control the play durations of the notes. A MusicXML file into MuseScore can control the play durations of the notes, but only by controlling the musical time allocations of the notes and letting the play durations ensue from that.
As to how much control it should have, that is of course a very complicated matter!
Now, my scores are not at all sophisticated. I generally assume that they will always be played by some non-descript General MIDI compatible synthesizer (much more primitive than you probably typically depend on).
But of course the play, as done by any such synthesizer, with the play durations at, for example, 100% of "face" will sound predictably different from the play, done by any such synthesizer, with the play durations at 85% of face.
So suppose I compose a score in Overture, and set all note durations to 85% of face, and play it through some nondescript General MIDI compatible synthesizer, and say, "oh, that's nice".
But I decide to use Finale for my work from now on, and I transfer this score to Finale via MusicXML. And now I have Finale play it though a different nondescript General MIDI compatible synthesizer. And the notes play at 100% of face. And I say, "Well, that's not what I had in mind!"
But now to get the sharpest point on this matter, Suppose that, the above notwithstanding, I join the view that we should not really look to have note play durations conserved, as written, when transferring a score from, say, Overture to MuseScore.
But currently MuseScore does not, as would be fully consistent with that outlook, just ignore the values of the duration elements in a MusicXML file. It does respond to them, but in a way that, in the scenario I just mentioned, produces a very peculiar result - a string of quarter notes rendered, in play, at a faster clip than befits a string of quarter notes.
I don't think that matches anybody's outlook on what should happen.
So perhaps one of two things should occur:
• "We" decide that trying to conserve play durations "as written" when a score is transferred via MusicXML file doesn't really make sense, and MuseScore should be made to just ignore the duration element, rather than doing something troubling with it (thus following the lead of Finale).
or
• "We" decide that conserving play durations "as written" is useful to some kinds of work we wish to support, and MuseScore should be made to respond to the duration element in a useful way (thus more or less following the lead of Overture).
But what I can't support is this outlook: "It is not really generally useful to conserve play durations "as written" when transporting a score via MusicXML into MuseScore, so we should leave MuseScore like it is, trying to do that but in an odd way that only creates mischief."
So we should "cure it or kill it".
You say, "it seems best to me to aim the xml at the target platform." Do you mean by that that the scores you create in Overture, when fully "refined" from a play standpoint, are predicated on being rendered on a certain sound producing device, perhaps associated with a specific notation program (perhaps different from MuseScore)?
Best regards,
Doug
In reply to A recommendation I recommend… by Doug Kerr
Hi, bob,
In suspect from your very interesting discussion of our workflow that an important route for the exchange of scores via MusicXML is between MuseScore and Sibelius.
I have never really used Sibelius, and as I mentioned I only have operating here a trial-time-expired trial version. But, partly because of my recent observations with that Sibelius as the receiver of a MusicXML file, I suspect that it, when generating a MusicXML file, does not encode any note play timing information into the MusicXML code.
Specifically, that would mean that the value of the mandatory element duration for all notes matched exactly the time value (notational duration - "quarter", "half", etc.) of the note. Type said "dozen", and duration said "12".
That means that the scores created in your MuseScore from such Sibelius-generated MusicXML files will not ever have any "mischief" in them from the phenomenon I have worried over here. So you are lucky in that regard.
But if it turned out that the notation program on the other end of these communications had been Overture, you might well have experienced this "mischief".
Thanks for staying with me on this. It is enough to make my old telephone engineer's head hurt. (I am nine years older than Alexander Graham Bell ever was.)
Best regards,
Doug
In reply to Hi, bob, In suspect from… by Doug Kerr
Well, I know nothing of Overture. Other than its current cost. That being roughly half of the cost of Sibelius the many years ago that I bought it. Then there is the cost of MuseScore.
In the old days, if you were a recording engineer, You mixed your recordings based on your target audience. That meant that if you were producing recordings for folks to play on their boom boxes, then you did mixdown on a boom box. And so forth. Those recordings wouldn't sound the same on any other system. And in truth, wouldn't anyway.
I would totally expect you to have to change settings in Overture to get the results you want in MuseScore. Each platform is set up to get the best results from.....itself.
If Sibelius "ignores" note durations, it might be because of that. Respect for control by the new platform. Maybe that is wishful thinking.
Personally, I use notation software for composition. As a result, it is the sound file that matters to me. I'm not even that interested in the score. Strange, I know. It's mostly for the therapeutic value. I find that transferring a file between platforms does not always sound as good as I had wished.