I noted that it was in fact possible to order same-time events in the Event List Editor,
it just depended which one you create first - Program or Note.
But ultimately it doesn't matter as I mentioned above, upon playing, the devices sort them properly.
But I reasoned that if we enforce this rule at the driver end, then we should enforce it at the
visual side such as in the Event List Editor.
After studying the situation I have applied a patch to the SVN trunk.
Our methods EventList::add() and ::move() now sort all same-time notes AFTER controllers,
similar to how our driver-side class M(idi)P(lay)EventList already did that.
This means, among other subtle things, the Event List Editor sorts same-time notes after controllers.
Note this is not perfect: Same-time controllers are not guaranteed to be in the same order each time,
and furthermore the sorting of controllers in the driver-side MPEventList is not guaranteed to be the
same order as the EventList.
With my original MPEventList sorting changes and these new EventList changes, I considered whether
to refine the sorting even more, for example ordering program controllers before all other controllers.
I'm not so sure there's a right way and a wrong way to do it.
What if a device wants program changes before controllers?
Conversely what if it is desired to send a volume change before program change to avoid a possible
tiny short audio glitch while switching programs?
(Of course these things can be done by manually spreading the event times.)
In any case, even with refined sorting, there is as Robert said no further mechanism by which
we could allow the user to pin specific same-time events to specific times.
In fact all of this automatic sorting is actually counter to allowing that!
Try the SVN trunk if you wish.
I'm not entirely sure about the code so it needs to be tested.
I tested as much as I could here and it seems to work so far.