In my MIDI-CI library I have implemented MIDI Message Report, and it seems interoperating enough with another initiator implementation. But now I am wondering what my client implementation should do when there are more than one MIDI Message Report responses in response to concurrent requests that my Initiator sent to ALL the discovered MIDI-CI endpoints (i.e. more than one).
Those endpoints can send responses back to my Initiator in parallel. Unlike other MIDI-CI messages, there is no Source MUIDs on those MIDI Message Report body as they are mere Channel Voice Messages. If they are returned in mixed order, I cannot reliably receive results.
IF I understand correctly, MIDI-CI is transport agnostic and there seems no premise on a MIDI transport that a MIDI-CI initiator that is connected to multiple MIDI-CI recipients has control over how those concurrent responses are processed (like, exclusively, or appropriately correlated somehow). Can I appropriately deal with those concurrent reports within current MIDI-CI v1.2 specification?
what my client implementation should do when there are more than one MIDI Message Report responses in response to concurrent requests that my Initiator sent to ALL the discovered MIDI-CI endpoints (i.e. more than one).
Interesting question...
Ideally for each UMP connection (or MIDI 1.0 Port) MIDI Message Report Should really be sent to one Device at a time. It is generally a message that is used sparingly.
If the Device supports ChCtrlLIst/AllCtrlList PE messages then you could compare the incomming CVM with the PE data perhaps?
It is good to know that my Q is not kind of dumb 😉
> If the Device supports ChCtrlLIst/AllCtrlList PE messages then you could compare the incomming CVM with the PE data perhaps?
To my understanding, more than one *same* MIDI-CI devices (different only in product instance ID / serial number) could be connected, and they would return the same ChCtrlList/AllCtrlList contents.
IMO if we are not supposed to send concurrent MIDI Message Report requests then it should be addressed somewhere in the specification.