I have recently had to import a number of musicXML files into Dorico 5. Gradual dynamics in the form of text never seem to work - they end up as system text instead of dynamics. I noticed this has been discussed before both here and in facebook groups with responses like “this is something we want to do but have not gotten around to yet” or “your source is not using the right syntax” etc. So I made a small test file including both hairpin gradual dynamics and text based (cresc. dim.). I created these files in Finale Notepad, Sibelius 2022, Musescore 4.5 and Dorico 5.1, exported them as uncompressed musicxml files and imported them into all of these softwares - including the original source. And I’m sorry to say that Dorico came out worst in this test. When importing from any of the other softwares the cresc. is converted into system text in Dorico. And if the musicxml comes from Dorico the text based gradual dynamic is now a hairpin - even when importing into Dorico again. The other softwares can handle it OK in any combination of source/recipient.
It would seem that the fault is in Dorico and it is quite tedious to have to edit all gradual dynamics in a score. Are there any plans to start implementing support for the full musicxml format in Dorico?
I’m not an expert in MusicXML, but here’s my take.
Dorico exports both hairpins and cresc/dim as <wedge> elements, which looks to be the way that gradual dynamics are represented. Inside Dorico, whether a gradual dynamic is drawn as a hairpin or as text is a property on the object, but it looks like MusicXML doesn’t have a way to convey that information. So when Dorico reads a <wedge> element, it creates a hairpin.
In Finale, I think actual gradual dynamics can only be hairpins. If you want cresc/dim, these get entered as expressions – that is, as text. Finale doesn’t really know what those words mean, even if you create them as expressions in the dynamics category. When Finale exports MusicXML, it represents hairpins as wedges, like Dorico, but a text “cresc.” is represented just as a <words> element, without any semantic information; when Dorico imports this, it renders text, because it doesn’t have any other information about it.
I suppose that Dorico could have logic to say that if there’s text that says “cresc” or “dim”, it should be rendered as a hairpin, but there are problems there as well. For example, what should the duration of that dynamic be? The XML from Finale doesn’t indicate a duration (because it’s just text). So maybe Dorico gives them a default short duration, but then you have to go through and set them all to the duration you want, and I don’t think that’s much of an improvement on the current situation. (I would say it’s worse, because it’s easier to locate “cresc.” in the score than it is locate hairpins that are too short.)
It is quite clear that Dorico thinks that “cresc” and < mean the same thing. That is something that is debateable, but I use Dorico to create sheet music - not to create a sound file. A “cresc” notation in the score often doesn’t have a duration the way a wedge/hairpin does. Its duration is thus more open to interpretation by the performer; do we crescendo until the next dynamic mark etc.
My intention with the little exercise I did was to identify how the various programs coded the gradual dynamics in MusicXML files and create a script to “fix” the output from e.g. Musescore so that Dorico would import it correctly. But it seems that Dorico is too concerned with playback at the cost of the accuracy of the printed music. The MusicXML files indeed use the element for “cresc.” and that is off course why Dorico treats it as text. But Dorico ignores the y position and the italic style that is also coded in the file - so I get the cresc. in normal letters above the staff instead of in italics below. If only Dorico would implement the vertical position and style of the cresc. I don’t really care if it plays back as a crescendo or not. After all it is a notation program not a DAW
It does if one knows how to assign the cresc. text.
I exported this from Finale, using a default document.
In MuseScore, the ‘cresc.’ comes in as a text Expression, not one of MuseScore’s ‘cresc’ dynamics.
In Finale, it comes in as a text expression. (Because Finale doesn’t actually have gradual dynamics as a concept.)
In Dorico, it also comes in as staff-attached text. Are you complaining about the fact that by default, staff-attached text is above the staff and in Roman style, rather than below the staff and in italics? Because that can be easily dealt with quite quickly, in a variety of ways.
I know that Dorico works that way. I’m talking about printed music. How can you tell from a handwritten manuscript (Beethoven, Brahms, whoever) how long they intended the cresc. to be? Sometimes they write cresc. - - - - - but sometimes just cresc. The former clearly has length, the latter not. It is open to interpretation by the performers. And I want to have my scores in Dorico as close to the original as I can. And when importing MusicXML the attributes that are in the HTML code should be respected. There are preferences I can set for MusicXML import in Dorico; one of them is “Import font style information” but that unfortunately does not seem to include italic. I am otherwise very happy with using Dorico and very impressed with the work the team is doing but this “bug” is driving me crazy having to go through the score and change every cresc and dim individually
You certainly don’t have to do that. Select them all in one go, and then perform the adjustments to all of them at once. F for flip, right-click Text > Change Paragraph Style.
You can select all the Staff-attached text either by Selecting one and then using Select More a couple of times, or filtering for text.
If there are other text markings that aren’t dynamics, you can Command click (or CTRL click on Win) to de-select those. Or if the cresc/dim marking are in the minority, just select one and then Command click each of the remainder.
It’s not instant, I’ll grant you, but it’s not a Sisyphean struggle either.
I quess that my whish is that Dorico would simply use the information that is already in the XML file:
Placement below the staff and italic font style is coded in the file; and other programs manage to implement that when importing MusicXML.
I have been experimenting with different types of text in Dorico to see how they are handled when exporting into and importing back from XML but have not found any workaround. I did find some strange behaviour, though. Some playing techniques such as “con sord.” or “arco” are recognized as a playing technique when I export from Dorico to XML and import it again. But others - e.g. “marcato” - are changed into staff text.
It’s not easy to figure out how Dorico does this; why is “arco” understood as a being playing technique when imported but “cresc.” is interpreted as staff text. They are both encoded in the XML file as “words”.