MIDI is being serial; however the tempo changes in the MIDI file are not (at least not in the same sense): They are information for the software playing the MIDI file - but they are not transmitted over MIDI itself. Of course the fact that everything else is serial would imply to treat them as serial as well; and I agree that the current way to handle this is akin to a design flaw or an oversight.
Regardless of the fact that no midi cable is being used, the protocol is still serial in nature. That is why, for example, VST and AU plugins process midi events in a "queue" which is serial in nature. A midi cable, or a midi queue, will have midi events only one at a time...in some order. Even LogicPro has an event list...which is a serialized list of midi events...and they will play in that order too! You just can't rearrange the order of two events in the event list if they have the same time stamp, LogicPro doesn't provide a way to do so.
Doesn't matter if you have 10 events in a row with the same timestamp, they are still processed one event at a time, in the order they are presented in the midi stream or queue...(or midi cable). that is not always how all software chooses to process the queue, but they usually cause problems for someone when they don't, because of the assumption about it being a serial queue. There are lots of computer processes that are serial in nature. How files are read and written, for example. Etc, etc. etc. Midi is no exception. If they make assumptions that they can ignore the order established by a sender, then they break the sender's intention.
I can recall that back in the day it was almost a science how MIDI data gets prioritized to improve timing and so on. When having multiple commands on the same timestamp - what gets sent first? Usually note events were prioritized over controllers and program changes were prioritized over note events
really are you sure about that? I don't think so. Especially back in the day. It could be that some merging boxes or something may have prioritized notes over CC's while merging, but once merged...serial protocol....one after the other in the order they come.
Now, how various software programs have decided to handle events on the same timestamp..that is another matter in many situations, but what I can say is that midi cables, midi interfaces, midi drivers...midi buffers...midi queues...VST/AU....they all process midi in a serial stream. Per this thread....midifiles are also serialized using delta times. They don't contain absolute timestamps. They are fundamentally serial in nature.
If some app chooses to ignore that ordering, then they will have problems like LogicPro is having now with this particular midi file...while some of the other apps aren't having a problem with it because they are respecting the serial ordering.
(this makes sense: when a program change and a note appear at the same time it's safe to assume the note should use the "new" sound - but it's bad practice anyway since the receiving device probably would need time to change the sound). On the other hand: Ctrl. #7 going down from 127 to 10 immediately after the note was played is also not a good idea so maybe this should get sent before the note, too. When having notes on multiple channels on different tracks: Which one gets prioritized? Top to bottom in the track layout? Top to bottom channel-wise? Or Channel #10 first (because drums are very timing-critical)?
All that you are describing has always been the responsibility of musicians to ensure that we put the events in the order we want them to be.
Perhaps the behavior in Logic is a remnant of this past. But I also think it should be fixed.
Steinberg has also been ignoring the serial nature of midi, Apple is not alone in this. The VST3 spec, for example, does not respect midi ordering at all...and is actually very unsuitable for certain types of midi plugins. Their response is that VST is not meant to be for midi...they don't care about it and don't want to acknowledge it, but I can tell you that on the VST dev forums there are plenty of people begging them to respect midi ordering, but they don't care...people have been complaining about it for 10 years, they don't care.
Kontakt also has a problem here. For example if you use CC switches to drive an instrument in kontakt...and if you have, say, a chord with different articulations on different notes of the chord...all on the same timestamp. Guess what happens? First, kontakt processes all the CC's before processing any of the notes..then it processes the notes. But in that case only the last CC is seen by the instrument. For example if you you needed CC58=1 for the articulation of the bottom note, and CC58=2 for the top note of the chord... which ever CC58 that was the last one, ends up being the articulation played by both notes.
Numerous people doing that kind of music will have various problems using Cubase Expression maps and LogicPro articulation sets when they try to use CC switches with Kontakt...often times they can't figure out what is going on and just complain that its all broken, but I can tell you the main problem is that Kontakt chooses to process all the CC's within a process block (which is actually much more then one timestamp, its a time range representing your audio buffer size). So all the CC's within that audio buffer span are processed before processing notes...and there are numerous situations where this failure to recognize the serial order of midi events that was sent to it, results in erroneous results and confusion to the musician.
VST3 has similar problems related to non-note events also, as those events are not passed to the plugin as a serial buffer, as was the case with VST2, AU, etc..