ref: 1da09bcd496be902cd99c0b5896ece1849d8e5c9
parent: d7e1d486d0930206d47dc9bd2aaef4a0f20bda3d
author: cancel <cancel@cancel.fm>
date: Tue Jan 21 14:01:51 EST 2020
Change ordering of args for send_midi_chan_msg() Makes more sense the new way, I think. I kept confusing myself with the old way.
--- a/tui_main.c
+++ b/tui_main.c
@@ -961,7 +961,7 @@
static ORCA_FORCE_NO_INLINE void //
send_midi_chan_msg(Oosc_dev *oosc_dev, Midi_mode const *midi_mode,
- int chan /*0.. 15*/, int type /*0..15*/,
+ int type /*0..15*/, int chan /*0.. 15*/,
int byte1 /*0..127*/, int byte2 /*0..127*/) { switch (midi_mode->any.type) {case Midi_mode_type_null:
@@ -995,7 +995,7 @@
}
#endif
U16 chan_note = start->chan_note;
- send_midi_chan_msg(oosc_dev, midi_mode, chan_note >> 8, 0x8,
+ send_midi_chan_msg(oosc_dev, midi_mode, 0x8, chan_note >> 8,
chan_note & 0xFF, 0);
}
}
@@ -1106,7 +1106,7 @@
// not. If it's not OK, we can either loop again a second time to always
// send CCs after notes, or if that's not also OK, we can make the stack
// buffer more complicated and interleave the CCs in it.
- send_midi_chan_msg(oosc_dev, midi_mode, ec->channel, 0xb, ec->control,
+ send_midi_chan_msg(oosc_dev, midi_mode, 0xb, ec->channel, ec->control,
ec->value);
break;
}
@@ -1113,7 +1113,7 @@
case Oevent_type_midi_pb: {Oevent_midi_pb const *ep = &e->midi_pb;
// Same caveat regarding ordering with MIDI CC also applies here.
- send_midi_chan_msg(oosc_dev, midi_mode, ep->channel, 0xe, ep->lsb,
+ send_midi_chan_msg(oosc_dev, midi_mode, 0xe, ep->channel, ep->lsb,
ep->msb);
break;
}
@@ -1156,7 +1156,7 @@
}
for (Usz i = 0; i < midi_note_count; ++i) {Midi_note_on mno = midi_note_ons[i];
- send_midi_chan_msg(oosc_dev, midi_mode, mno.channel, 0x9, mno.note_number,
+ send_midi_chan_msg(oosc_dev, midi_mode, 0x9, mno.channel, mno.note_number,
mno.velocity);
}
}