I think a bigger problem is within updateMatchedPairs itself.
As of today if it encounters two consecutive noteOn events with same note number and midi channel without a corresponding noteoff between it creates a new noteOff object and puts it between. Thus screwing up perfectly valid midi sequences.
There’s nothing wrong with consecutive noteOn events (with the same note number and midi channel) although some ambiguity might occur as to which noteOn a certain noteOff belongs.
The midi specification (the “real” one, downloadable from midi.org) even states something along the lines, -it’s up to the instrument to decide what to do when consecutive noteOn’s with same note number is received. So it’s not exactly any unheard of behaviour.
What the midi spec states is merely that for every note on event there should be a corresponding note off event. E.g you could stuff all your noteOffs at the end of the sequence and it would still be valid midi. I’m not saying it would be particularly useful though…
So why would you want to have consecutive noteOn events with out noteoffs between? There’s plenty of reasons.
You might just want to beef up your sound by doubling the notes, making more voices sound at the same time, at best giving you a chorus like effect (if your synth permits this of course, but then again, it’s up to the synth to decide).
You might have a guitar synth you want to mimic a 12 string guitar by doubling the notes/voices/strings.
In your drum synth you might want to play a cymbal crescendo by feeding it a bunch of noteOns with increasing velocity. This will probably sound daft if there was any intervening noteOffs between the strokes. At least if the drum machine implemented noteOffs to mimic hand muting.
I believe for a few versions ago (talking about ver 3 or 4), there was no call of updateMatchedPairs in midi file open, giving you the opportunity to use your own updateMatchedPairs(). I wish we could bring back that behaviour. Not only for things mentioned above but also because it’s probably rather time consuming (although I haven’t benchmarked it myself, I must confess).
It might not be noticeably when opening a single file, but if you have a midi library you might want to open hundreds of midi files to collect things like length, bpm, authors and other meta data to show in a browser or whatever. This would probably take some time, especially since updateMatchedPairs is executed twice for every track due to copying of the midi sequences.
So I guess this ends up in two humble suggestions…
-
Make updateMatchedPairs non-manadatory again or at least make it possible to furnish your own updateMatchedPairs() function.
-
Skip the insertion of noteOffs between consecutive noteOns with same note number and channel in updateMatchedPairs