[m-voParticipant]

This unfortunately turns out to be a major issue for our application. 🙁

When sending too many MIDI messages (esp. larger ones like setting labels) to the MR, execution of the MIDI commands halts completely and then – after a while – is executed at the normal speed again. No messages seem to be dropped, though. It’s just as if the worker reading the buffer stops working for a time but input still being queued. To be honest, this would be a rather silly implementation of rate limiting. 🙂 So I assume it’s likely a bug.

What is even worse: MIDI messages, sent by the MR (as a result of the requested commands), could also get slowed down. If you hit the above condition and have sent enough data, it could take several minutes (!) after the outgoing messages have been completely sent. It’s about only 1-2 message(s) per second then. During this time, it is impossible to retrieve status information (e.g. messages to get fader/send level/mute status…) as they simply seem to get queued afterwards.

How to reproduce:
1. Open up two connections, one where you send lots of data (for instance label all Ip channels), one where you listen to the announced changes.
2. The first messages will be received with little delay, after a while they appear super slow.
3. When monitoring the same thing in the dLive Director, you’ll notice the execution of the commands halting at some point (you might try sending scene recall messages in between, so this gets better observable).

Possible solutions:
* A quick fix could maybe be to loosen the constraints and allow a bigger rate per time unit. I’m hitting these limits even with rate limiting on my side and it’s very hard and cumbersome to work around the limitations. All in all the sent payloads are super small compared to the available network bandwidth.
* If stalling the MR/Director is an issue, there should IMHO be a smoother throttling at the input side (sliding window, currently feels like its a fixed one). But not sure this is really an issue, as the system seems to be perfectly OK with being hammered by multiple Director instances…
* A more sophisticated solution could be to selectively drop queued messages if they would get overridden without side effects by a later one (e.g. for labeling/coloring/muting/setting fader and send levels).
* Currently, there is no feedback send for commands on the same connection. So, for instance requesting to “mute channel A”, won’t issue a “channel A muted” message. In order to build a stateless system or to monitor states, you’ll always need a second connection (which I assume also eats up the budget). Not sure if this is a feature and changing it would be considered a BC break or it’s a bug.

Feel free to contact me for more information. I’m very happy to help track this issue down and improve the situation.

[m-voParticipant]

Alright, I did submit a ticket. This might be worth adding to the pinned thread, wouldn’t it? 🙂

[m-voParticipant]

> https://support.allen-heath.com/hc/en-gb/requests/new

That’s neither an issue tracker nor a form to submit bugs (!= “Technical Support”), though.

[Author]

Posts