#1610 Midi file seems to slightly break Rosegarden's import (link inside)
This midi file seems to slightly break import: https://github.com/abique/midi-parser/files/7212564/test.mid.zip What happens is that over half the tracks just have no names, even though some are named as expected with their General Midi/GM instrument name, but not all of them. The mysteriously unnamed tracks also don't have the correct GM program set in the instrument parameters. Even more interestingly though, playback seems fine with all tracks playing with even unnamed tracks using correct GM instruments (as far as I can tell), somehow the instrument assignment just doesn't make its way to the UI for half the tracks.
Since I haven't seen this happen with any other midi file, and loading it up in my own midi playback tool lists all instruments with General Midi assignments for all tracks just fine, I suspect this is a bug...? My apologies if not.
My best guess without looking is that the Bank Selects and Program Changes are not at time zero for the problematic tracks. When we import, BS/PCs at time zero end up in the "Instrument Parameters". All others are simply brought in as events which can be seen in the event editor.
It all works because either way, "Instrument Parameters", or events, the BS/PCs go out.
We want to preserve the time that the BS/PCs were sent out, so we have to do things this way.
I'll need to take a close look at the MIDI file to be sure. But I suspect this is working as designed.
I had a look at this and Ted is right. In the tracks with the default name the program change is not at time zero.
But the program change is before the first note !! There are only some rests before it.
So the question is can we replace the "zero time" criteria with a "before first note" condition. This would of course make the program change go out at a different time - but still before the fist note.
I think this would certainly fix the track names.
OK - just did a quick hack and replaced
if (event.getAbsoluteTime() > 0)with
if (event.isa(Note::EventType))in MidiFile.cpp.
All the tracks (except the drum track) in the given midi file have a suitable name !
Can we go with this change ?
disadvantages ?
?
Thanks for confirming my suspicions.
I don't think fixing this is a good idea as there are likely situations where the timing of the PC is important. E.g. some synths choke when they get too many PCs all at once.
Otherwise, switching to Instrument Parameters after import is easy. Bring up the event editor, make a note of the BS/PC, dial them up on the Instrument Parameters for that track, and delete the BS/PC events.
We could have a command or an import preference to let the user decide how to handle this. But since there is a straightforward workaround, I'm not sure it's worth it. Maybe if somebody has to import 500 MIDI files. They would appreciate some automation for this. No one has asked, though.
What if the instrument parameters showed the first program change info anyway, but stored/remembered internally with marker that the event still exists and the event wasn't removed, and as long as the event instrument isn't changed there is no duplicate program change saved/sent to devices from the instrument parameters due to that stored/remembered marker? Or is that too complicated?
Basically, I feel like the states "instrument parameters show instrument", and "program change was at 0 seconds and will be exported as such again" don't need to be linked like that with no additional flag/marker to possibly distinguish that. But maybe I'm just overcomplicating this idea
It's an interesting idea, but most folks just dial up what they need and forget about it. Either that or they use program changes directly in their segments.
I could imagine a "delay" field (actually absolute time) added to allow for specification of a delay before the first PC is issued. But that does feel really complicated. Not sure what sort of problems it might cause both for implementation and use.
Hm I see. For what it's worth, the only reason I'm even suggesting it is that Rosegarden's midi import otherwise is really intuitive and excellent, so it seemingly sometimes failing to "detect" the instrument just seemed a bit out of character to me when I ran into it. I have never had anything unexpected happen outside of this, it's working really well.