Understanding the MIDI import panel wrt instrument names and quantization
I'm transcribing music for someone else. They've produced a MIDI file which unfortunately has all the tracks in a single channel with the piano sound and I can't really fix this without loading the MIDI into a different editor first, which seems to defeat the point of using Musescore. (Note that the attached sample MIDI file is unreleased copyright material and should not be used for any purpose except demonstrating the problems below). I am currently using Musescore 2.0.3 in the default package as supplied with Fedora 25.
The MIDI file contains a voice track and two keyboard tracks. When you load this MIDI file, the first apparent problem is that the voice part has been placed in a grand staff with the first keyboard part. I understand why this has happened, but the MIDI importer really needs a way to say don't do that. The "MuseScore instrument" selection only gives me different pianos - would be nice to have something that would allow me to select from the full palette of instruments.
The really weird thing about this is that if I select "split staff" for the first keyboard (it's already selected for the second), the resulting layout is (a) a grand staff with the voice part and RH of the keyboard; (b) a grand staff with the LH of keyboard 1 and the RH of keyboard 2, and (c) a single staff with the LH of keyboard 2. This surely has to be the wrong thing to do in almost all circumstances? It gets more complicated when there are more voice or instrument parts (given, as I say above, that they have all been recorded in channel 1 of the MIDI file).
So given that, together with the fact that the split staff algorithm really doesn't do a good job, as discussed in Issue #154651, what I have to do is just import it and then copy+paste all the music into a fresh score with the correct layout, and then manually split the piano staves. It's irritating, but it's workable.
Suggested fixes: (a) some sort of tickbox in the import dialogue which lets me say whether a grand staff is required or not; (b) let me choose other instruments during the import (and don't put them on a grand staff if they shouldn't have one); (c) let me choose to disable the dynamic split algorithm and choose a fixed split point. (Supplementary and slightly off-topic: (d) let me choose individual notes on the grand staff that should have been rendered into the other hand and have them moved.)
Now, about the quantization: it appears that MuseScore is giving me the option to select the granularity of the quantization grid, but it's not working.
In Edit->Preferences->Import, select "Shortest note: Eighth". In "Max quantization" on the MIDI import panel, also select "Eighth". Press Apply. In bar 20 of the resulting score, there's a 32nd-note rest followed by a dotted 16th-note. These are also scattered about the score in subsequent bars. How can that happen when the shortest note is supposed to be an eighth? When playing back the score these rests result in a lack of synchronisation that isn't apparent when playing the MIDI file.
| Attachment | Size |
|---|---|
| 17.mid | 3.41 KB |
Comments
All 3 part was shared same output midi channel.
![channel-0.png]( "channel-0.png")
example:
1. Use an midi editor and made channel numbers different.
2. save as another name.
3. Then import again in Musescore.
example: Free midi editor: Sekaiju.
---
For quantization, use Sekaiju also...
Select all channels: in Edit Menu > Quantize >
For 8th: select 120 semiquaver.
press OK
Save.
FWIW, without understanding all the ins and outs of this, I'd say if you are provided with a poorly-organized MIDI file, and your goal is to turn this into notation, then pre-processing this in a dedicated MIDI program is an excellent idea. I don't see why you'd say cleaning up those error would "defeat the point of using Musescore". The point of using MuseScore is to produce a readable score. If spending some time improving the quality of the input before getting to MuseScore helps with that, then you are serving that purpose, not defeating it.
As for "quantization", that term is not really entirely accurate with regard to MuseScore. Or at least, it doens't mean the same thing to a notation program that it means to a sequencer. MuseScore won't deliberately notate notes shorter than specified *if it has a choice*. It will round things off as appropriate if it can do so and still preserve the same sequence of notes and procession of beats, etc. But if you've got four equally spaced notes in a beat, those are going to be represented as sixteenths pretty much no matter what other options you choose. The algorithm is complex enough - and I don't understand it myself - that I can't say for sure what might be going on in this particular case. But it sure sounds like you've presented MsueScore with one of those types of cases - two notes within half a beat, there's no way to represent that using just eighths, so it gives up.