05-27-2021, 09:49 AM
I have an MRCC on order. One thing I want to do with it is connect a device called MMM (Massive MIDI Modulator) that generates what is potentially a very large number of MIDI CC messages. It has a (class compliant) USB-MIDI output, and I would ultimately like to merge its output with that another device (a sequencer, which is also capable of USB-MIDI output) and send the resulting stream to a 5-pin MIDI port on a third device (a Nord Drum 2 drum synth).
The Nord has no USB-MIDI capability. That means that either of the devices feeding it might generate MIDI faster than the 5-pin port can handle. That is very unlikely to be a problem with the sequencer, but might be a problem with the MMM.
I can think of two possible ways of handling this problem:
1) Put incoming MIDI messages in a queue as they arrive, and send them to the output as fast as possible.
2) Put incoming MIDI messages in a separate queue for each input device, and give priority to one of the inputs when deciding which messages to transfer to the output.
In my particular application, (2) is far preferable, because it means that if the MMM generates bursts of MIDI messages, that does not cause the messages from the sequencer to arrive late, only the modulation messages, which don't need to be precisely timed anyway.
However, there is still the problem of what to do when the queue (or one of the queues) overflows.
I have a suggestion, if you are not already doing this: If you're going to throw messages away, how about trying first to discard messages that appear to be redundant. In particular, if the queue appears to be filling up, and you are about to process a CC message, perhaps it might be worth looking to see whether there is already another CC message for the same channel, device, and CC number, and, if so, discarding the earlier one.
This strategy may be too simplistic. However, it seems to me that any device that turns USB MIDI into DIN MIDI might have to deal with thinning the MIDI stream somehow; and at the very least it would be nice to know how MRCC is going to do that, and perhaps to have some control over it.
The Nord has no USB-MIDI capability. That means that either of the devices feeding it might generate MIDI faster than the 5-pin port can handle. That is very unlikely to be a problem with the sequencer, but might be a problem with the MMM.
I can think of two possible ways of handling this problem:
1) Put incoming MIDI messages in a queue as they arrive, and send them to the output as fast as possible.
2) Put incoming MIDI messages in a separate queue for each input device, and give priority to one of the inputs when deciding which messages to transfer to the output.
In my particular application, (2) is far preferable, because it means that if the MMM generates bursts of MIDI messages, that does not cause the messages from the sequencer to arrive late, only the modulation messages, which don't need to be precisely timed anyway.
However, there is still the problem of what to do when the queue (or one of the queues) overflows.
I have a suggestion, if you are not already doing this: If you're going to throw messages away, how about trying first to discard messages that appear to be redundant. In particular, if the queue appears to be filling up, and you are about to process a CC message, perhaps it might be worth looking to see whether there is already another CC message for the same channel, device, and CC number, and, if so, discarding the earlier one.
This strategy may be too simplistic. However, it seems to me that any device that turns USB MIDI into DIN MIDI might have to deal with thinning the MIDI stream somehow; and at the very least it would be nice to know how MRCC is going to do that, and perhaps to have some control over it.