short note cuts off long note in other voice on same staff
Musescore needs to separate voices into separate channels per track. In other words, voices on the same staff should be assigned to separate MIDI channels in the same Track. Example: a bass clef which is the second clef in a grand staff should be Track 2, with tenor and bass voices assigned to channels 1 and 2 respectively.
Note: I had posted this previously as part of another thread, and received this response from ericfontainejazz:
"Regarding [the text above], to separate voices into separate channels per track, I'm not sure this is the most desirable, since voices are nothing more than separate voices. They aren't separate instruments, and they might not even be for separate musicians....for instance in the case of voices of a piano part, so I would lean to not putting voices on separate tracks. Having each voice on a separate channel might just complicate things, and make it harder for ordinary 99% use case where user wants all voices of same part to be synthesized the same. Again, I don't know of any definitive official standard...this is just my personal opinion."
My reply:
I didn't previously explain the problem very well. This is a basic MIDI issue. It doesn't have to do primarily with different instruments or timbres on one staff, although being able to do that is a benefit of solving the problem. The issue has to do with properly tracking and assigning MIDI Note ON / note OFF events both in MIDI files and in live MIDI output.
For example, write these two voices on a staff (see attached .jpg and .mscz files):
- 1st voice, scale in 16ths starting at MIDI C60, CDEFGABC
- 2nd voice C half note.
Play it back with a violin patch, and you'll notice that you don't hear a sustaining C, as the half not C gets cut off after the first 16th note because the MIDI data is not being separated into two channels. When the data is on one channel, the Note OFF message from the other voice is not linked to that voice, so it's going to turn off any sounding C60.
MIDI can't be parsed correctly in MIDI files output from MuseScore when multiple voices are one one staff. All notation software that I know of allows the user to assign MIDI channels to voices, in order to be able to handle MIDI output properly. That's why I've classified this as a bug, although it may sound like a feature request. Thanks.
P.S. I also found this forum post about this topic at https://musescore.org/en/node/205546 I checked the MIDI file output from his example project (opened it as .mscz, exported as .mid file, opened that in other software) and MIDI channels are correctly assigned.
Attachment | Size |
---|---|
musescore_MIDI_bug.jpg | 15.28 KB |
separate_MIDI_channels.mscz | 3.4 KB |
Comments
Sorry my description above is so meandering ...
I hope it's clear that this is a basic issue in polyphonic keyboard music.
For example, organ music having any voice crossing or overlapping will play back incorrectly in MuseScore, and MIDI files of this music output from MuseScore will not be parsed correctly by the importer.
See #12971: Same note in different voices and lengths plays only the length of the shortest note
I think the OP mixes up diagnosis of symptoms (correct) with the proper cure (incorrect).
The bug in current MuseScore is that MS sends a note-off event to early. The correct cure is
to delay the note-off event until the last participating voice leaves that note (so some
increment/decrement/refcounting needs to be impemented).
Voice->Channel mapping would be a nice new feature (but please don't make it the default).
N.B.: the idea that MIDI channels where intended to express voices is simply absurd (remember, only 16 channels available)
Automatically closed -- issue fixed for 2 weeks with no activity.
Automatically closed -- issue fixed for 2 weeks with no activity.
Automatically closed -- issue fixed for 2 weeks with no activity.
Automatically closed -- issue fixed for 2 weeks with no activity.
Automatically closed -- issue fixed for 2 weeks with no activity.
Automatically closed -- issue fixed for 2 weeks with no activity.
Automatically closed -- issue fixed for 2 weeks with no activity.