Where is the official documentation on the musicxml "standard". I checked the w3.org site which I presumed is the standard and it states that:
The <pitch> element requires an <alter> element, even if the accidental is already in the key signature. Although the <alter> element does not change how the pitch is notated, it ensures proper playback and transposition.
With respect to the accidental parameter:
The <accidental> element represents actual notated accidentals.
Thanks for the detailed example more_complex_quintuplets_new.cognac.
Here's what the notation looks like internally (parameter only visible in development):
Are you sure it's the best choice to split and tie the 1/10 notes in bar 2 into 2 * 1/20 only because they happen to cross a beat? It's probably pure chance that this beat lands exactly in the middle. With a different time signature, it's no longer the case and you'll get dots and whatnot in addition to the tie. I'm not a piano player, but the split and tie seem to somehow obfuscate the rhythm, which is a straight series of quintuplets spanning the first half and second half of the measure here.
I may be wrong, but If all notes of a tuplet are supposed to be split and tied where ever they happen to cross a beat, the score will look a lot more complex. Just imagine time signature 6:8 and the many ties that will ensue.
Intuitively I would rather let a tuplet run until it (or a rest completing it) ends on a beat.
Thanks a lot for taking the time to respond and explain.
Experiments show that forcing the alter element to be present (even if zero) and leaving the accidental element out seems to work. In traditional keys, notation programs should have no problem choosing the proper accidental to print.
Gb Major, as it shows up in the Circle Of Fifth widget, will be exported as six flats. Six sharps would be F# Major, which however doesn't occur anywhere in Synfire. This is also consistent with how LilyPond interprets the key.
I've already improved the selection and combination of rests for the next update. It will consider more context, i.e. what's happening before the run and after and whether beats are met in between. It looks at thousands of permutations and picks the one with the least unwanted properties.
I may be wrong, but If all notes of a tuplet are supposed to be split and tied where ever they happen to cross a beat, the score will look a lot more complex. Just imagine time signature 6:8 and the many ties that will ensue.
When you have music with quintuplets, ties between notes of two tuplet segments are not a problem to read and are common in classical music.
That said, you have two options. The picture that I attached in this post is related:
As you can see, C1 and C2 are equivalent. Now pretend there's a longer note somewhere between the beats. If you're using C2, and you need a tie, you necessarily have to put the tie, of course. If you use C1, you won't need it because you can just change the duration of the note.
However, choosing C1 or C2 is a complex thing, and I delved into that in the linked post, but it can be changed in the notation program anyway. The most important thing IMHO is that what's inside Synfire is correctly reflected to the notation. When there are equivalent situations, those can be changed later in the notation program.
Concerning Synfire's decision, I would probably use C1. But we'll see tanders' opinion.
One thing I wanted to note is concerning the dot character. While UTF-8 would offer nice options graphically, we need something that can be written into an input field by the user easily. Hence I decided for the asterisk now, which is universally available on all international keyboard layouts. The degree sign was not.
@andre: Thanks for considering these tuplet options so carefully!
> Are you sure it's the best choice to split and tie the 1/10 notes in bar 2 into 2 * 1/20 only because they happen to cross a beat?
As often, it depends. For this particular example, I prefer the tied notation I shared for reasons outlined below, but I think it might be best to first start with the basic principles here.
The definite guide on notation matters for me is Gould's Behind Bars, She discusses this very matter in chapter 7 on Tuples, subsection Degree of note division within a tuple (p. 210f). These pages are part of the Google Books previewed I liked above (unfortunately I cannot link to that specific page, but I copy the core fragment as a screen short).
According to Gould, it indeed depends, namely it depends on whether it is more important that performers are able to count certain subdivisions (e.g., the beat) for a precise ensemble performance, or whether it is more important to have the tuplet "flow" as a whole.
As you can see in her examples, you might initially think that the top-most option is by far the simplest (does not need any ties at all), but as I said, depending on the context the last option with most ties can be the best, because there all beats of the time signature are clear and can be counted.
Now, coming back the the example I initially shared (more_complex_quintuplets_new.cognac), I would personally feel the notation option I shared that shows all the inidividual beats would be particularly suitable here, because these tuplets are more complex than those in Gould's examples, and splitting them into shorter tuplets -- each one 1/4 beat long -- would help a performer to read/perform the rhythm, because she can internally keep a 1/20 pulse throughout the bar, and can then precisely align the beats (on every 5th 1/20 note) with her internal pulse as a reference.
By contrast, Andre you are suggesting to avoid the ties with longer tuplets over two 1/2 notes. With such a notation, I think the performer of this rhythm would still need to internally keep a 1/20 pulse anyway to perform these short note durations reasonably accurat, but that would mean she would loose the rhythmic reference points at beat 2 and beat 4, without really gaining anything.
So, if there are such short rhythmic values involved (1/20 -- and here even 1/40), then I would strongly prefer the tied notation, because the performer would need to count a faster pulse anyway. Then why not show the beats that fall on those pulses for better rhythmic orientation... Does that make sense?
Option C2 (with three individual triplets) makes clear the positions of the beats in the bar, and it would therefore help to perform this rhythm more accurately rhythmically. By contrast, I feel option C1 (one long tuplet across the whole bar, and beaming across halve bars) could be preferrable if you want that tuplet rhythm be performed with some rubato or some other rhythmic inaccuracy. Indeed, it seems we agree on this distinction here (you instead write that C2 would be better if accents are important, and C1 if they are not).
If we need to agree on a single default here for Synfire to export, personally I would prefer option C2, because that is the standard case, and I would then manually refine this in a notation editor as needed.
If we need to agree on a single default here for Synfire to export, personally I would prefer option C2, because that is the standard case, and I would then manually refine this in a notation editor as needed.
For 2.0.5 the Rhythmic Figurations example was a very helpful guide. Although it is currently not possible to meet all its preferences, but it comes close (see attached file). Even MuseScore can't restore some formatting when importing its own exported XML, e.g. where beams are crossing measure bounds, tuplet brackets get lost, etc.
The number of possibilities to split and tie notes is huge. It's easy to code the rules, but very hard to balance their priorities. I decided for a minimal approach that splits at measure bounds and certain beats depending on time signature.
With "rhythmic_figurations.cognac", it looks fine opening with MuseScore, but importing with Dorico results in a mess; empty measures starting from measure 16, and triplets also are weird. This may be an indication that the XML file is not written very well?
> looks fine opening with MuseScore, but importing with Dorico results in a mess
Have you tried exporting MusicXML again from MuseScore and importing that with Dorico? Unfortunately, for practical reasons the level of MusicXML support of these programs differs, and sometimes seemingly they even do not actually support the recognised standard but some deviation of the standard used by some competitor. :headache:
Weird. Synfire processes and verifies a score measure by measure, so it should be very unlikely that something midway through a file would corrupt everything that comes after. I would expect individual measures with specific errors, but not something broken like this.
I would suggest following tanders' suggestion, for tuplets that go on for an entire measure, but only for the common ones, 3 and 5, which are the only ones we have anyway right now, and divide them per-beat, which is the standard case.
Sibelius is another tool we use to test XML validity. It opens Rhythmic Figurations without problems.
Exporting from MS to Dorico however does work, so it's Synfire's fault. I've made a diff and the reason why the triplets are weird in Dorico is because below actual-notes and normal-notes, MuseScore also adds <normal-type>eighth</normal-type>
The problem with measure 16 is actually measure 15, and it's the exact same problem. So, by not understanding measure 15, Dorico ruins all the following ones, and so on.
The documentation also confirms that it's the way to go:
If the type associated with the number in the <normal-notes> element is different than the current note type (e.g., a quarter note within an eighth note triplet), then the <normal-notes> type (e.g. eighth) is specified in the <normal-type> and <normal-dot> elements.
MuseScore reads everything right anyway because as it's been said already it is pretty good with XML.
To better explain these normal-type and normal-dot tags, for what I understand, tuplets works fine out of the box if they are all the "simple value" only, e.g. an eight note in a eight-notes-triplet, inside a 4/4 measure. As soon as one of the note in the triplet has a different duration, you have to write what that is, by using the normal-type tag; the same concept is for dots inside triplets.
As a side note:
<rest></rest>
can simply be
<rest/>
Same for the tuplet tag, just do
<tuplet type="start" bracket="yes"/>
etc.
No need to write the long version.
after importing the file "2. from MS to MIDI.mid", if you use "Auto" for the Prep, it gets "1/16 + Quintuplets" and it checks "Expect Quintuplets", and it doesn't check "Expect Triplets", even though there's nothing but triplets.
By changing manually, exporting actually works fine.
So, by not understanding measure 15, Dorico ruins all the following ones, and so on.
Thanks for digging out the normal-type issue. There's a lot of redundancy in the format that's driving me nuts. I don't yet get why those elements aren't clear from the context (after all, MuseScore and Sibelius can figure it out) but will certainly grasp it at some point. Notation is one of the worst data representation formats invented by humankind ever. Although incredibly beautiful.
<rest></rest>
Trivial, but we don't write anything to the file directly. XML is an object and the library serializes it as it sees fit. It doesn't matter.
It uses one single triplet for all the measure.
I tried the C2 example and it creates separate beam groups per beat as expected. I thought this was foremost about beaming. Is a separate bracket per beat really more helpful than knowing in advance that nothing will change for the entire measure? And with quarter triplets (1/3), would you really want such a simple triplet split into 4 brackets with tied notes? Doesn't that also depend on context, style and overall density/tempo?
It's hard to cover aesthetic and performative preferences for all time signatures and rhythm patterns. I'll check if there's a simple rule that works for most cases here but can't spend too much time on it at this time.
According to the specs, normal-type and normal-dot elements are optional. If they were required, we would have added them from the start and the XML schema wouldn't validate in the first place. They may be useful for specific cases (nested tuplets?), but the basic tuplets we have for Synfire should not need them.
It's the responsibility of the importing program to figure out the note head and dots from duration, type and time-modification (redundant). Successfully tested with MuseScore, Sibelius and Finale.
Unless there is a simple static mapping we could add in order to placet Dorico, I'll leave at this for now.
Sa., 01.10.2022 - 19:40 Permalink
[redacted flame]
So., 29.05.2022 - 00:16 Permalink
Where is the official documentation on the musicxml "standard". I checked the w3.org site which I presumed is the standard and it states that:
With respect to the accidental parameter:
Sa., 01.10.2022 - 19:41 Permalink
[redacted wrong MusicXML stuff]
So., 29.05.2022 - 17:01 Permalink
@tanders:
Thanks for the detailed example more_complex_quintuplets_new.cognac.
Here's what the notation looks like internally (parameter only visible in development):
Are you sure it's the best choice to split and tie the 1/10 notes in bar 2 into 2 * 1/20 only because they happen to cross a beat? It's probably pure chance that this beat lands exactly in the middle. With a different time signature, it's no longer the case and you'll get dots and whatnot in addition to the tie. I'm not a piano player, but the split and tie seem to somehow obfuscate the rhythm, which is a straight series of quintuplets spanning the first half and second half of the measure here.
I may be wrong, but If all notes of a tuplet are supposed to be split and tied where ever they happen to cross a beat, the score will look a lot more complex. Just imagine time signature 6:8 and the many ties that will ensue.
Intuitively I would rather let a tuplet run until it (or a rest completing it) ends on a beat.
So., 29.05.2022 - 17:26 Permalink
@scriabiner
Thanks a lot for taking the time to respond and explain.
Experiments show that forcing the alter element to be present (even if zero) and leaving the accidental element out seems to work. In traditional keys, notation programs should have no problem choosing the proper accidental to print.
Gb Major, as it shows up in the Circle Of Fifth widget, will be exported as six flats. Six sharps would be F# Major, which however doesn't occur anywhere in Synfire. This is also consistent with how LilyPond interprets the key.
I've already improved the selection and combination of rests for the next update. It will consider more context, i.e. what's happening before the run and after and whether beats are met in between. It looks at thousands of permutations and picks the one with the least unwanted properties.
Sa., 01.10.2022 - 19:42 Permalink
[redacted wrong MusicXML stuff]
So., 29.05.2022 - 22:37 Permalink
When you have music with quintuplets, ties between notes of two tuplet segments are not a problem to read and are common in classical music.
That said, you have two options. The picture that I attached in this post is related:
(https://users.cognitone.com/comment/19668#comment-19668)
As you can see, C1 and C2 are equivalent. Now pretend there's a longer note somewhere between the beats. If you're using C2, and you need a tie, you necessarily have to put the tie, of course. If you use C1, you won't need it because you can just change the duration of the note.
However, choosing C1 or C2 is a complex thing, and I delved into that in the linked post, but it can be changed in the notation program anyway. The most important thing IMHO is that what's inside Synfire is correctly reflected to the notation. When there are equivalent situations, those can be changed later in the notation program.
Concerning Synfire's decision, I would probably use C1. But we'll see tanders' opinion.
Mo., 30.05.2022 - 18:10 Permalink
One thing I wanted to note is concerning the dot character. While UTF-8 would offer nice options graphically, we need something that can be written into an input field by the user easily. Hence I decided for the asterisk now, which is universally available on all international keyboard layouts. The degree sign was not.
Di., 31.05.2022 - 11:54 Permalink
In that case, it should at least be explained in the Embedded Help / tooltips.
Mi., 01.06.2022 - 11:19 Permalink
@andre: Thanks for considering these tuplet options so carefully!
> Are you sure it's the best choice to split and tie the 1/10 notes in bar 2 into 2 * 1/20 only because they happen to cross a beat?
As often, it depends. For this particular example, I prefer the tied notation I shared for reasons outlined below, but I think it might be best to first start with the basic principles here.
The definite guide on notation matters for me is Gould's Behind Bars, She discusses this very matter in chapter 7 on Tuples, subsection Degree of note division within a tuple (p. 210f). These pages are part of the Google Books previewed I liked above (unfortunately I cannot link to that specific page, but I copy the core fragment as a screen short).
According to Gould, it indeed depends, namely it depends on whether it is more important that performers are able to count certain subdivisions (e.g., the beat) for a precise ensemble performance, or whether it is more important to have the tuplet "flow" as a whole.
As you can see in her examples, you might initially think that the top-most option is by far the simplest (does not need any ties at all), but as I said, depending on the context the last option with most ties can be the best, because there all beats of the time signature are clear and can be counted.
Now, coming back the the example I initially shared (more_complex_quintuplets_new.cognac), I would personally feel the notation option I shared that shows all the inidividual beats would be particularly suitable here, because these tuplets are more complex than those in Gould's examples, and splitting them into shorter tuplets -- each one 1/4 beat long -- would help a performer to read/perform the rhythm, because she can internally keep a 1/20 pulse throughout the bar, and can then precisely align the beats (on every 5th 1/20 note) with her internal pulse as a reference.
By contrast, Andre you are suggesting to avoid the ties with longer tuplets over two 1/2 notes. With such a notation, I think the performer of this rhythm would still need to internally keep a 1/20 pulse anyway to perform these short note durations reasonably accurat, but that would mean she would loose the rhythmic reference points at beat 2 and beat 4, without really gaining anything.
So, if there are such short rhythmic values involved (1/20 -- and here even 1/40), then I would strongly prefer the tied notation, because the performer would need to count a faster pulse anyway. Then why not show the beats that fall on those pulses for better rhythmic orientation... Does that make sense?
Mi., 01.06.2022 - 11:37 Permalink
@scriabiner
> Concerning Synfire's decision, I would probably use C1, see https://users.cognitone.com/comment/19668#comment-19668
Option C2 (with three individual triplets) makes clear the positions of the beats in the bar, and it would therefore help to perform this rhythm more accurately rhythmically. By contrast, I feel option C1 (one long tuplet across the whole bar, and beaming across halve bars) could be preferrable if you want that tuplet rhythm be performed with some rubato or some other rhythmic inaccuracy. Indeed, it seems we agree on this distinction here (you instead write that C2 would be better if accents are important, and C1 if they are not).
If we need to agree on a single default here for Synfire to export, personally I would prefer option C2, because that is the standard case, and I would then manually refine this in a notation editor as needed.
Mi., 01.06.2022 - 22:04 Permalink
Makes sense to me.
Mi., 08.06.2022 - 20:40 Permalink
For 2.0.5 the Rhythmic Figurations example was a very helpful guide. Although it is currently not possible to meet all its preferences, but it comes close (see attached file). Even MuseScore can't restore some formatting when importing its own exported XML, e.g. where beams are crossing measure bounds, tuplet brackets get lost, etc.
The number of possibilities to split and tie notes is huge. It's easy to code the rules, but very hard to balance their priorities. I decided for a minimal approach that splits at measure bounds and certain beats depending on time signature.
Sa., 01.10.2022 - 19:43 Permalink
With "rhythmic_figurations.cognac", it looks fine opening with MuseScore, but importing with Dorico results in a mess; empty measures starting from measure 16, and triplets also are weird. This may be an indication that the XML file is not written very well?
[rhythmic_figurations_in_dorico.jpg]
Do., 09.06.2022 - 21:17 Permalink
> looks fine opening with MuseScore, but importing with Dorico results in a mess
Have you tried exporting MusicXML again from MuseScore and importing that with Dorico? Unfortunately, for practical reasons the level of MusicXML support of these programs differs, and sometimes seemingly they even do not actually support the recognised standard but some deviation of the standard used by some competitor. :headache:
So., 12.06.2022 - 13:25 Permalink
By the way, just as a reminder for the devs, even if the MusicXML documentation sucks, there are plenty of examples like
(https://www.w3.org/2021/06/musicxml40/musicxml-reference/examples/tutor…)
that can be used to clarify doubts.
Do., 09.06.2022 - 21:32 Permalink
Weird. Synfire processes and verifies a score measure by measure, so it should be very unlikely that something midway through a file would corrupt everything that comes after. I would expect individual measures with specific errors, but not something broken like this.
Do., 09.06.2022 - 21:35 Permalink
The chromatics examples work fine though.
Do., 09.06.2022 - 21:45 Permalink
It looks like we got Measure 16 From Hell ;-) If you can spot something unorderly in this XML, let me know. To me it looks clean and simple as soap.
Sa., 01.10.2022 - 19:44 Permalink
I would suggest following tanders' suggestion, for tuplets that go on for an entire measure, but only for the common ones, 3 and 5, which are the only ones we have anyway right now, and divide them per-beat, which is the standard case.
Fr., 10.06.2022 - 12:03 Permalink
Synfire chooses the C2 variant by default.
Sibelius is another tool we use to test XML validity. It opens Rhythmic Figurations without problems.
Fr., 10.06.2022 - 14:54 Permalink
No it doesn't? 2.0.5, try it. It uses one single triplet for all the measure.
So., 12.06.2022 - 13:25 Permalink
Exporting from MS to Dorico however does work, so it's Synfire's fault. I've made a diff and the reason why the triplets are weird in Dorico is because below actual-notes and normal-notes, MuseScore also adds
<normal-type>eighth</normal-type>The problem with measure 16 is actually measure 15, and it's the exact same problem. So, by not understanding measure 15, Dorico ruins all the following ones, and so on.
The documentation also confirms that it's the way to go:
Dot example: https://www.w3.org/2021/06/musicxml40/musicxml-reference/examples/normal-dot-element/
MuseScore reads everything right anyway because as it's been said already it is pretty good with XML.
To better explain these normal-type and normal-dot tags, for what I understand, tuplets works fine out of the box if they are all the "simple value" only, e.g. an eight note in a eight-notes-triplet, inside a 4/4 measure. As soon as one of the note in the triplet has a different duration, you have to write what that is, by using the normal-type tag; the same concept is for dots inside triplets.
As a side note:<rest></rest>can simply be<rest/>Same for the tuplet tag, just do<tuplet type="start" bracket="yes"/>etc.No need to write the long version.
Fr., 10.06.2022 - 18:36 Permalink
In this old example here:
(https://users.cognitone.com/comment/19786#comment-19786)
after importing the file "2. from MS to MIDI.mid", if you use "Auto" for the Prep, it gets "1/16 + Quintuplets" and it checks "Expect Quintuplets", and it doesn't check "Expect Triplets", even though there's nothing but triplets.
By changing manually, exporting actually works fine.
Fr., 10.06.2022 - 19:28 Permalink
Thanks for digging out the normal-type issue. There's a lot of redundancy in the format that's driving me nuts. I don't yet get why those elements aren't clear from the context (after all, MuseScore and Sibelius can figure it out) but will certainly grasp it at some point. Notation is one of the worst data representation formats invented by humankind ever. Although incredibly beautiful.
Trivial, but we don't write anything to the file directly. XML is an object and the library serializes it as it sees fit. It doesn't matter.
I tried the C2 example and it creates separate beam groups per beat as expected. I thought this was foremost about beaming. Is a separate bracket per beat really more helpful than knowing in advance that nothing will change for the entire measure? And with quarter triplets (1/3), would you really want such a simple triplet split into 4 brackets with tied notes? Doesn't that also depend on context, style and overall density/tempo?
It's hard to cover aesthetic and performative preferences for all time signatures and rhythm patterns. I'll check if there's a simple rule that works for most cases here but can't spend too much time on it at this time.
Sa., 11.06.2022 - 16:14 Permalink
According to the specs, normal-type and normal-dot elements are optional. If they were required, we would have added them from the start and the XML schema wouldn't validate in the first place. They may be useful for specific cases (nested tuplets?), but the basic tuplets we have for Synfire should not need them.
It's the responsibility of the importing program to figure out the note head and dots from duration, type and time-modification (redundant). Successfully tested with MuseScore, Sibelius and Finale.
Unless there is a simple static mapping we could add in order to placet Dorico, I'll leave at this for now.
Sa., 11.06.2022 - 17:28 Permalink
Oh, ok. I guess that's something to report to the Dorico team, then.
Do., 20.10.2022 - 14:35 Permalink
I hope that after V2 is stable enough we could get back to the issue of tuplets and notation. :)