Dorico not putting complete tempo map in XML?

I want to use Dorico XML in Cantamus or Ace Studio. I’ve got a theatrical piece with a lot of tempo alterations. All of the tempi are in the MIDI, but not in the XML. There is a tempo map in the XML, but with more than half the entries missing.
I’m hoping that down the way Dorico finds a way to export the complete midi tempo map in the xml. Given the proliferation of AI vocal generation tools, this would be very timely and very useful!
Thank you, and I’m sorry if I’ve bumped the topic or whatever.

We’ll need more information to be able to help here. Can you provide a minimal Dorico project that, when you export it to MusicXML, is missing tempo items? And can you please be specific about which tempo items you believe it is missing?

Thank you for coming on the thread.
The file I had an issue with had originated in Finale, was imported to Dorico via xml, and I redid the tempos in the Dorico file, and they failed to export completely.
In response to your reply, I made a short Dorico file, compared the XML and MIDI tempo output, and they match. Same number of entries, including some low numbers, so there’s no filtering being done by Dorico.
This is a head-scratcher. I wonder if there’s a way to clear all the xml tempo info out of a file coming in from Finale and start over with tempos in Dorico? I was able to reproduce the issue with a Finale file… but not Dorico.



Tempo.dorico (559.0 KB)

Well, don’t attach the project that does work as you expect :slight_smile:

We need to look at the project that is resulting in tempos going missing when you export MIDI.

Not a short one… here it is… definitely has missing entries in the XML.
Sorry, couldn’t upload txt files, sent screenshots instead
01 Everybody Needs a Dream.dorico (3.2 MB)


I hit the same problem in these last few days, but not having to do directly with dorico. A complicated tempo map got normalized or quantized with the result that the musicxml material really did not in fact match the original. Not only were tempo changes quantized to a quarter note beat, but they were rounded off to the nearest integer.

For the OP, you can look in the musicxml file with any text editor and see the tempo changes as musicxml reports them. Search for “metronome”.

Edit … where the quantizing and rounding off matters is in very low tempos, which one might use especially in theatrical material to introduce pauses appropriate for the sound but not directly notated in the score. The difference between mm 120 and 120.4 is tiny, but between 20 and 20.4 gets noticeable, and especially if the 20.4 actually happens 2/3 of the way through a quarter note rather than on the beat.

And found this random statement on somebody’s internet post … I don’t think it’s true but it is scary if it is taken as truth: FALSE NEWS, I HOPE: ** "Set Tempo meta event can change these defaults. As MIDI only deals in quarter notes, the Set Tempo meta event also only deals in quarter notes " **

Here is how a midi tool (gnmidi) represents the tempo as generated by a DAW:

/* U0 / / M001.1.000 / / 0ms / trackname “Marian Motets”
/
U0 / / M001.1.000 / / 0ms / copyright “c 2025 William Copper”
/
U0 / / M001.1.000 / / 0ms / text “William Copper”
/
U0 / / M001.1.000 / / 0ms / text “Keywords: CLASSICAL CHORAL INTONALISM ORCHESTRA\x0a”
/
U0 / / M001.1.000 / / 0ms / text “This file: reduced tracks for midi export\x0a”
/
U0 / / M001.1.000 / / 0ms / tact 8 / 4 24 8
/
U0 / / M001.1.000 / / 0ms / key “1# maj”
/
U0 / / M001.1.000 / / 0ms / beats 111.5799535455 / 537731 microsec/beat /
44; /
U44 / / M001.1.044 / / 24ms / beats 111.2600759906 / 539277 microsec/beat /
131; /
U175 / / M001.1.175 / / 98ms / beats 111.1000011110 / 540054 microsec/beat /
349; /
U524 / / M001.1.524 / / 294ms / beats 110.9399759260 / 540833 microsec/beat /
305; /
U829 / / M001.1.829 / / 466ms / beats 110.7800019940 / 541614 microsec/beat /
131; /
U960 / / M001.2.000 / / 540ms / beats 110.4600107146 / 543183 microsec/beat /
305; /
U1265 / / M001.2.305 / / 712ms / beats 110.2999976102 / 543971 microsec/beat /
131; /
U1396 / / M001.2.436 / / 787ms / beats 109.9799469897 / 545554 microsec/beat /
131; /
U1527 / / M001.2.567 / / 861ms / beats 109.8199136449 / 546349 microsec/beat /
131; /
U1658 / / M001.2.698 / / 936ms / beats 109.6599445121 / 547146 microsec/beat /
131; /
U1789 / / M001.2.829 / / 1010ms / beats 109.3400055034 / 548747 microsec/beat /
262; /
U2051 / / M001.3.131 / / 1160ms / beats 109.1800397051 / 549551 microsec/beat /
131; /
U2182 / / M001.3.262 / / 1235ms / beats 109.0199470163 / 550358 microsec/beat */

and here how the musicxml represents it ( brackets in musicxml may make it look missing but it’s here)

quarter 112 1920 1 quarter 111 -1898 quarter 110 -1440

same material showing musicxml with leading angle brackets deleted show it is visible

direction placement=“above”>
direction-type>
metronome parentheses=“no” default-x=“-37.67” relative-y=“20”>
beat-unit>quarter
per-minute>112
/metronome>
/direction-type>
sound tempo=“112”/>
/direction>
note default-x=“373.49” default-y=“-10”>
rest measure=“yes”/>
duration>1920
voice>1
/note>
direction placement=“above”>
direction-type>
metronome parentheses=“no” default-y=“24.76” relative-y=“20”>
beat-unit>quarter
per-minute>111
/metronome>
/direction-type>
offset>-1898
sound tempo=“111”/>
/direction>

What did it have to do with?
These files are highly portable, and some other app might have quantized it, depending on the settings. The bit about midi only dealing in quarter notes is demonstrably untrue, given the data showing in this same thread.

That’s exactly how the data shown was derived. One came from a DAW’s tempo list, the other a Find list in BB edit for the term “tempo”