midiout does not seem to reliably send MIDI CC data faster than once msg per 25ms
In Max for Live I am trying to send high res 14 bit CC messages - so that requires me to send a LSB and MSB CC message. I am generating these in response to an external input where the changes can be very fast so I can be generating a lot of messages in some cases.
I have that all working fine in terms of what I sending to the midiout - but I've noticed that in the MIDI monitor I am using to check the output that CC messages are getting dropped.
I've mocked up a really simple fragment here to send 4 CC messages in quick succession. With the delays all removed (replaced with a t b b b b to sequence the messages) only one CC message is actually sent - this is always the last message in the sequence.
With delays in place more messages get sent as I put the delay between the messages up - so for example with a 20ms delay three cc messages acutally get sent - but I can only reliably send all four messages when I have a 25ms delay between each CC message.
So I guess midiout is either doing some rate limiting or some output buffer is getting overwritten before the message can be sent.
Given that even old style hardware MIDI can send over 1000 CC messages a second this rate limiting to 40 per second seems quite extreme.
Is this expected or am I doing something wrong? Is there a faster midi output I should use instead?
This works fine for me. No dropped messages even with the delays removed. What midi monitor are you using?
Despite Live being timing disaster, one needs to form midi messages in proper order for msb lsb or nrpn stuff
look at this midi strain test.
Uzi ramps 128 * 128 controllers/values which makes 49152 bytes.
this is macbook from 2011, max 8.1.11, system el.capitan,
midi over IAC buss.
after 80 ms every single byte has ben received.
midi in / out objects drop repeated status byte and CC number,
so real number of byts transmited is actualy lower,
but midiin did output all 49152 byes needed by receiver of midi messages.
Thanks @submo and @Source Audio
The messages I am sending in my patch are all properly formated my midiformat - with the demo patch I just wanted to make the simplest test patch I could make to show the issue. I am totally expecting repeated CC messages to be dropped for example.
I am using the MIDI monitor that comes as standard in Midi Effects (in Suite anyway) - it has MPE support and presumably is the latest.
However when I replace that with the MIDI monitor from M4L essentials all the CC messages come through fine even with no delay.
So the bug is in the new MIDI monitor.
Thanks for helping me resolve this.
maybe that midi monitor is not made for fast messages.
if you create many repeated messages, I woud not count
on midi omitting full message, only staus byte and ev. CC number.
to really send only changed CC values one can't use midiformat,
rather use list and filter using zl.change.
this might look a bit overkill, but it will guaranteed output no repetition,
and reacts to any change, can be extended to more than 2 inputs.
The newer MIDI monitor is definitely broken - when replaced with the old M4L Essentials one all the messages show up fine from my patch as I expected them to.
That is a good point about zl.change to catch the repeated messages - but in my case I don't think my patch will create many repeated CC messages because I have something further up the signal chain that only passes messages if they change by a certain amount - this is because the input signals are being filtered so when they reach a steady state we can stop sending further changes.