Wrong Midi channels in connected parts

• Feb 5, 2019 - 14:24
Reported version
3.0
Type
Functional
Frequency
Once
Severity
S2 - Critical
Reproducibility
Always
Status
active
Regression
Yes
Workaround
No
Project
MuseScore

1) Configure at least two instruments
2) create connected parts
3) export parts to *.mid files
4) inspect *.mid file of part #2 in appropriate SW, e.g. a DAW

Result in MS3: midi channels start at 2 or even higher, depending on number of channels in part #1
Expected & result in MS2: midi channels starts at 1 in every part exported as midi file.
This is a regression from MS2

Comments

• Feb 28, 2019 - 12:50

Maybe I should explain a little bit why this is important to my workflow:

I use the midifiles generated form parts, not the whole score to feed my DAW packed with VST instruments. My DAW is configured to directly use those part-midi-files. After each change (even small ones) I export the part midi files and therefore overwrite the files in the DAW, which automatically re-reads them. This way I use Musescore more or less as an editor for my DAW (just in one direction, of course).

I use a tweaked instrument.xml giving me 6 midi channels per instrument, which I use to select different articulations in my VST instrument. I have templates for those instruments with some standard sustain sound on channel 1, more expressiv on channel 2, marcato on channel 3, etc .... which I change using staff text.

In MS2, each part started with midi channel 1, so I could directly use my templates without having to readjust the midi channels. In MS3, the midi channels will depend on the position of the instrument within the score: The first one will have 1-6, the second 7-12, the third one 13-16 + 1-2, etc ...

If I would now adjust the VST to those channels and insert aother instrument in Musescore, I would have to redo the channel assignment.

Reply

• Feb 28, 2019 - 22:34

Still, though, that's no different than if you used a workflow that was based on the score to begin with? Seems you are making it harder on yourself my needing to deal with all those parts. Especially since you can now choose port & channels per instrument in the mixer. But, I don't how that would work with your special instruments.xml

To me, the advantage of the current system is (presumably) the same channels regardless of whether dealing with the socre or parts. That seems a pretty significant advantage to me. But I admit to not actually using any of this in any way; I'm just speculating that others might have the sort of workflow for which the new scheme is better, and it does seem quite logical to me.

Bottom line, I'm not sure there is answer to please everyone here.

Reply

• Feb 28, 2019 - 23:42

If I export the score, I have to go to the DAW, import the file, assign it to the proper tracks each time I do the export from Musescore. It takes several minutes to do that. Another limitation is that I would be restricted to 16 midi channels in total. My typical scores have 15-20 staves, with 6 midi channels each, i.e. I would required 90 - 120 separate midi channels. In one file this does not work because they get mixed up.

The way I do it, I import and make the assignment in the DAW only once. After each further export overwriting the DAW files, every midi note is automatically on the right track and right articulation. I takes me less than 2 seconds between making a change in Musescore and hearing the result in the DAW.

I know that it is not possible to please everyone. My suggestion would be to do a readjustment of the midi channels only at the very end when writing the midi files in exportmidi.cpp, probably only in parts, not in master score if it is possible to identify it there. That would do not harm to anyone and should not interfere with the mixer. I will try to do a prototype and then make a pull request if it works.

Reply

• Mar 2, 2019 - 08:27

Marc said: "Especially since you can now choose port & channels per instrument in the mixer. But, I don't how that would work with your special instruments.xml"

That's interesting! I tried it and ... well yes it works .... or let's say I can get it to work. This gives me at least 16 staffs (16 ports) - should do in many cases, as there are typically 1 - 5 vocal staves which are not need as midi files and therefore could share one port.
When I add an instrument, I have to manually adjust port and channel of each instrument (e.g. 15) and each articulation channel (6). That's 90 adjustments additional work compared to MS2, but OK, it's needed only once.
There is some strange behavior here: When I set the port of the instrument, only the first two channels are set, the remaining one stay an an other port. It would be good, if setting the port of a staff all channels under that instrument could at least be set to that port. I would be even nicer, if setting the port would also assign the channels like 1,2,3,4, ...

I attached score where the channels are correct and also my tweaked instrument.xml (-> EWQL_CCH_Library.xml).

Looks like I'm now going to switch my working environment to MS3 :-)

Attachment Size
Strings.mscz 14.01 KB
EWQL_CHH_Library.xml 42.16 KB

Reply

• Mar 2, 2019 - 11:26

I said: "Looks like I'm now going to switch my working environment to MS3 :-)"
Well, seemingly that was a little bit overhasty.

After making all the adjustments in the mixer I
- saved the file and
- quit Musescore, then
- reopened the file again.
Result: In the mixer everything looked fine, but when I export the midi files an inspect the files in the DAW's midi editor, I see that the instrument changes by staff text - used as articulation changes in my case - are ignored. All Notes are on midi channel 1.
I think this is definitely unwanted behavior.
I will open an new issue on this.

Reply