There are some issues with current MIDI low-level stuff that will backfire if not taken care of.
Namely, it is built around an assumption that incoming MIDI messages are 3 bytes long. As far as I can tell, longer messages will be truncated, and shorter are just assumed to not exist.
Working on a midiClock module I noticed that longer messages (like MTC full frame) are sent out in a few batches of 1-3 bytes each. I'm not sure how RtMidi handles that, but probably we'd be better off with generalizing kernelMidi::send to work with messages of arbitrary length and increase chances that RtMidi will pass them as a single message, just as intended.
Same problems with received messages. MIDI devices tend to work with internal state machines that don't care about small delays between consecutive bytes, and again, I'm not sure what RtMidi treats as a single multi-byte message, and what might as well arrive to Giada broken into a few pieces. I'm especially worried about MTC full frames, which are 10 bytes long.
That being said, midiDispatcher will play a major role in a ton of changes I'm working on. Message lengths will vary from single-byte Midi Clock, through variable-length CCs, to 10-byte MTC frame.
The question is whether we can blindly trust in RtMidi's sanity that messages passed to Giada will be always parsed into the logically consistent chunks. Or if we should aim towards building internal buffer and enforce correct parsing and dispatching.
The answer is probably somewhere in RtMidi's docs. :)
Anyway, just wanted to notify everyone what I plan to do, hopefully get a green light from @monocasual, let them tag the issue properly, get an issue number to name the branch somehow, listen to some opinions et cetera.
Hey @Jackojc, we are about to ship a pretty cool MIDI overhaul in the next version of Giada, especially the sync part with other instruments (master/slave mode). Stay tuned
There are some issues with current MIDI low-level stuff that will backfire if not taken care of.
Namely, it is built around an assumption that incoming MIDI messages are 3 bytes long. As far as I can tell, longer messages will be truncated, and shorter are just assumed to not exist.
Working on a midiClock module I noticed that longer messages (like MTC full frame) are sent out in a few batches of 1-3 bytes each. I'm not sure how RtMidi handles that, but probably we'd be better off with generalizing kernelMidi::send to work with messages of arbitrary length and increase chances that RtMidi will pass them as a single message, just as intended.
Same problems with received messages. MIDI devices tend to work with internal state machines that don't care about small delays between consecutive bytes, and again, I'm not sure what RtMidi treats as a single multi-byte message, and what might as well arrive to Giada broken into a few pieces. I'm especially worried about MTC full frames, which are 10 bytes long.
That being said, midiDispatcher will play a major role in a ton of changes I'm working on. Message lengths will vary from single-byte Midi Clock, through variable-length CCs, to 10-byte MTC frame. The question is whether we can blindly trust in RtMidi's sanity that messages passed to Giada will be always parsed into the logically consistent chunks. Or if we should aim towards building internal buffer and enforce correct parsing and dispatching. The answer is probably somewhere in RtMidi's docs. :)
Anyway, just wanted to notify everyone what I plan to do, hopefully get a green light from @monocasual, let them tag the issue properly, get an issue number to name the branch somehow, listen to some opinions et cetera.