Manually deleting this tag (which is a GP8 informational field), eliminated the error.
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.
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:
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)
There are many spurious dynamics, not sure where these are coming from:
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:
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.
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.
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.
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?):
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.
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:
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.
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.
@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
