Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Ordering of simultaneous events
When I insert a program change at a point in the song with note events the program change comes after the notes. Is it possible to explicitly specify the order of simultaneous events?
I don't think there is a way, will try to find out some more.

I've added functions to the List editor to increase/decrease the tick, could this be a solution?

Hi sorry late reply.

Extract from our file muse/mpevent.cpp:
(These are the actual playback events sent to devices and so on)

bool MEvent::operator<(const MEvent& e) const
{ ... Stuff ...
if (channel() ==
return type() == ME_NOTEOFF
|| (type() == ME_NOTEON && dataB() == 0)
|| type() != ME_NOTEON; // Make note-ons last so that controllers such as program come before notes played. 1/31/2012 Tim.
.. More stuff...

Yep, I thought I took care of that.
You appear to be the victim of the Graphical sorting of the event list.
However the actual playback should be as stated in that comment up there.

If you run with the -M option you can trace midi output in a terminal.
See the options with muse2 -h.

So here's what I get with a program at bar 2 followed later by two notes and a program at the same time:

MidiOut: Jack: <M-Audio-Delta-1010LT:midi/capture_1>: time:4401202 port:0 chan:1 type:0xc0 a=41 b=0
MidiOut: Jack: <M-Audio-Delta-1010LT:midi/capture_1>: time:4509863 port:0 chan:1 type:0xc0 a=66 b=0
MidiOut: Jack: <M-Audio-Delta-1010LT:midi/capture_1>: time:4509863 port:0 chan:1 NoteOn a3(0x45) 70
MidiOut: Jack: <M-Audio-Delta-1010LT:midi/capture_1>: time:4509863 port:0 chan:1 NoteOn f3(0x41) 70
MidiOut: Jack: <M-Audio-Delta-1010LT:midi/capture_1>: time:4515373 port:0 chan:1 NoteOn a3(0x45) 0
MidiOut: Jack: <M-Audio-Delta-1010LT:midi/capture_1>: time:4515373 port:0 chan:1 NoteOn f3(0x41) 0

Yes, looks like it's still working.

HTH. Tim.
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.


Forum Jump:

Users browsing this thread: 1 Guest(s)