Import MusicXML from GP8 quirks

Guitar Pro 8-> Export MusicXML. Dorico → Import MusicXML

  1. Import hiccuped due to this element:

Manually deleting this tag (which is a GP8 informational field), eliminated the error.

  1. Now somehow the instruments are not aligned to each other. There is a vocal instrument which has many rests at the start of the score (until vocal melody starts later), yet in the Dorico, there are only half a dozen empty measures then the vocal starts.

  2. The vocal track has many areas where there should be a full bar rest, but there is no rest, just completely blank measure in Dorico:

  1. The GP8 score has Section marks which are translated to Rehearsal Marks, this is expected, but beyond 26, things get interesting (see same pic above), with multiple letters, so perhaps the import should just switch all Rehearsal Marks to Number format instead of Letter, if importing more than 26. (Too bad Section names are not imported as System Texts)

  2. There are many spurious dynamics, not sure where these are coming from:

  1. System Texts are still not imported, it seems.

  2. Bends (guitar) seem to be missing. Tab seems to be ok though…

Overall there is manual cleanup to be done, this is what I noticed so far in quick skim.

Someone is bound to ask you to create a diagnostic report for this if not also to post the XML file.

In general I suspect the MusicXML export from Guitar Pro is somewhat quirky. There’s only so much Dorico can do to make sense of MusicXML that has eccentric encoding, because we can’t know what the original document looked like. If importing from Guitar Pro is important to you, you might well get better results importing the Guitar Pro file itself directly into MuseScore, and then exporting MusicXML from MuseScore to bring into Dorico.

I imported a different GP file using XML and MIDI and compared them. The XML import in this case is very strange because there is only a single bar number for the entire score (bar 1) because the top instrument (which is empty, in GP) has been interpreted as a single huge bar spanning multiple pages, while the other instruments have proper notes and barlines but no bar numbers within this region. Maybe Dorico is taking time from the topmost instrument, which, since it is empty, causes strange results.

The project has many tempo changes. The MIDI import yields tempo signposts sometimes and tempo marks other times. Why? This is the mid file import:

This is what the GP score looks like; the tempo marks are legit and should not be signposts (?).

The XML has many lines ‘failed’ due to these:
ERROR - Element ‘direction’, attribute ‘enclosure’: The attribute ‘enclosure’ is not allowed.
At line 77753 of …

This is the line. I am guessing it is the timestamp marker which GP allows to be inserted above any staff (indicates mm:ss time at that position, handy in transcribing). The CDATA is probably encoding “00:49” (mm:ss). Dorico should have imported this as System Text (with a rectangle border) .

In comparing these files I ran into an unwelcome Dorico UI condition:
In file1, Setup>edit expression map (expression map editor window is open)
Now from Finder, open midi file, which would be file2, but Dorico is unable to proceed with file2 because the expression map window is open, and error-chimes at various window clicks until the expression map window is closed; then Dorico proceeds to import.

I come across this limitation frequently and share your frustration.

It’s quite common for MIDI files to have a lot of small tempo changes that are just there to provide rhythmic feel or rubato, so Dorico’s import has a heuristic that successive tempos that differ by less than a fixed amount will be hidden. (Our ref: STEAM-8471.)

This is invalid MusicXML. It’s the “words” element that can have an “enclosure” attribute, not the “direction”.

It’s not really a limitation. If a modal dialog is showing, the application is blocked. This is true not only for Dorico but for all applications that implement modal dialogs following OS conventions and using their APIs.

Sorry. From this user’s perspective it is a limitation (notwithstanding technical issues, which I freely admit I don’t understand).

I find it intensely frustrating that I cannot ‘park’ the expression map window whilst I go and check something else.

I can understand that, of course. Some of Dorico’s more complex dialogs would be more comfortable to use if they were modeless, so that they don’t block interaction with the rest of the application (like e.g. the options dialogs, or Project Info). Making complex dialogs modeless, however, is itself a complex task, because you have to cope with myriad situations that can’t arise if changes can’t be made under your feet while the window is open.

1 Like

Importing Drum kit instruments: hihat hits.
GP → XML → Dorico or GP → Musescore (open the .gp file natively) → XML → Dorico are the same in this respect.
XML makes the open-hihat look visually similar but instrument voice/playback technique is lost:

If importing MIDI, the results are much better, as Dorico inserts a playback technique and creates a Groove Agent SE VST instrument from the drum kit midi instrument. But visually, I doubt any jazz drummer wants to see the “o” above the noteheads (they would want the circle-X notehead, right?):

Screen Shot 2024-04-04 at 11.56.37 AM

Ok. Maybe the window that prints these errors, can be made better, for example, uniq all the same errors and then list the lines of occurance, or, at least make the window bigger (if there is 1 import error of a specific type, then there are typically going to be dozens of instances of that same error, on different lines). Ideally the window would be in a matrix visualization (ie sorted table) but maybe that isnt worth the effort.

Attempting to get my Midi notes into my project has a strange copy-paste behavior leaving many tied notes.

  1. open midi file in dorico (from: GP .gp → opened in Musescore → Export as midi). highlight & copy some drum notes. (all these notes are Upstem Voice 1)

  2. open dorico project. attempt to paste into drum staff. Not sure what is going on here, a bit of a guess: the 16th prior to the open hihat note is double what it should be, and the open hihat note is being tied until the next open hihat note, etc.

At one point in this editing, I had a completely black window for content of the Drums instrument when switching to Galley view (Page View showed ‘tacet’). Apparently because the ‘Drums 1’ instrument, in my fiddling with flows and midi importing directly into a flow, became unassigned to any flows, and so, showed only a black screen (?) in Galley view only. (If the instrument is not assigned to any flows…shouldnt Dorico simply show… well I dont know what it should show, but not all black and probably not ‘tacet’ either.)
Page view:

Galley view:

MIDI import vs. XML import; driving me nuts. The XML import is sometimes correct (but yields incomplete bar signposts, very tricky to fix); the MIDI is sometimes correct (but yields incorrect tuples); neither are correct overall.

GP8 measure, which is correct (4/4):

Top staff, is MIDI import. Bottom staff, is cut&pasted XML import.

Musescore open of .gp file, same measures:

Where is the spurious triplet coming from when Dorico imports the MIDI, leading to the next measure being incorrect? There are several places in the piece which have similar problems.

I might have to just send this file so that the Dorico team can verify the MIDI import algorithm or something.

It will be embedded in a poorly constructed XML from GP8.

(You could improve the MIDI import by changing the quantization settings)


No it won’t be, when I am looking at MIDI file, not XML file.

A MIDI file has no concept of a tuplet.


It seems you do not know what is going on in my example, so I don’t know why you are commenting on it.

@superblonde no need to answer so harshly to someone that is trying to help you!

@Janus is correct (and he very well knows what is going on): midi doesn’t contain informations how to display a tuplet. Is the receiving program that decides how to visualise the rhythm based on the position of the midi notes in the grid of the (hypothetical) piano roll, and based on the quantisation settings of the receiving program. If the music in GP8 was not exactly quantised, when exported, then there are various possibilities to interpret those distances and note length etc. In this case Dorico interprets the 8 32nd notes group meticulously, based on its quantisation settings (that you can adjust afterwards also for selected passages, with selecting and then Edit>Requantize*) and decides to write it as you see in your example.

*it seems that in this case you have to select the 8 32nd and the first three notes of the next bar, and in the requantizing windows choose 32nd as value and uncheck tuplets