midi import quantization values problem

Hello

I have this small midi file containing 32nd notes sextuplets which are perfectly quantized from my DAW.

No success at all transcribing it in Dorico.
32nd notes seems to be the smallest possible subdivision in the quantize options.

Is there any chance this will be further improved in the future ?

Best
Yan

Can you zip up and attach the MIDI file here, Yan?

Here you go Daniel
Thanks

All the best
Yan
Vn-Solo quant probClipping.mid.zip (1.15 KB)

I’ll show this to Paul. It’s certainly at the edges of what Dorico’s quantization algorithm can cope with at the moment.

Thanks Daniel

I really hope he can do something about it.
twelve 32nd’s in a beat is really not that much uncommon, so Dorico should allow for a smaller quantize resolution if needed.

All the best
Yan

Hello

Again with this topic of quantization with midi import.
Look at what I get today.
My first jpeg shows what Finale (for example) is giving me (which is correct in this case)
I had to use Finale to get the right result and export a xml to open in Dorico since I was unable to find a setting that could transcribe accurately my midi file.
The second jpeg shows Dorico’s import for the same midi file…
The issue here is about transcribing quantized quintuplets (coming from a sequencer)

Best
Yan


If you want to provide us with the MIDI file, we can look into this at some point.

Here you go Daniel.
This is real issue for me…

Best
Yan
MINIATURE 1 Clipping.mid.zip (1.03 KB)

Paul and I have discussed this a bit. Dorico comes at MIDI import from the point of view of a probabilistic approach (in other words, what is most likely to be the expected result given particular input). If you have very precisely quantised music so that things like quintuplets are tick-perfect, I would suggest that you export MusicXML from the application in which you’ve quantized the music, rather than expecting Dorico to produce precisely the same result: you should hopefully find that this works reliably. We’ve discussed whether it makes sense for us to perhaps allow Dorico’s MIDI import to operate in a more “literal” mode, but I think our feeling in general is that if possible, using a more semantic and descriptive format like MusicXML for this kind of import is the better way to approach this workflow.

Hello Daniel

Thanks for your answer.

I tried the xml suggestion but I was not able to get the right result either.

The midi was exported to xml via Digital Performer 10 on perfectly quantized quintuplets.
So the midi is right but the xml is wrong already here.

Tried in Reaper with the same bad results.

For the moment, the only choice I have to save me time is to transcribe the midi in Finale then send it via xml to Dorico.
Horrible perspective for me indeed…

I hope you consider giving the user the choice wether to use a literal midi mode or the probabilistic one when transcribing.
I wish I understood the benefits of this probabilistic approach. I my case it’s not very efficient most of the time (this thread started in 2019)

Best
Yan

Could you attach the MusicXML exported from Digital Performer? It would be interesting to see what that looks like.

Hello Daniel

Here you go.

But look at the pictures attached.
In the first pic you see the midi data in the tracks (I did two version, with one being legato to see of if could get some better results)
In the second pic you see the QuickScribe notation of this in DP. It’s already wrong there…
No wonder the music xml is not going to be right. It is based on the QuickScribe transcription.

I get the same thing in Reaper, the notation is wrong.
If I can’t get my midi correctly transcribed in any DAW, then Finale is my only way in between the DAW and Dorico :frowning:

Best
Yan
Quintuplet-example.xml.zip (3.06 KB)


Thanks, Yan. Indeed, if the QuickScribe window doesn’t show the right results, obviously the MusicXML won’t be correct either. Is it possible for you to adjust the quantization settings in QuickScribe to get the notated result you want?

Hi Daniel

No unfortunately…
Same in Reaper.

Best
Yan