MIDI data flooding / limiting and Opendeck reset

[9bit-se]

Hi!

Thank you for making the excellent L Board and web configuration interface, it has shortened the development times significantly for several projects

However I have some questions and / or suggestions: The latest customer has a problem with what I think is MIDI data flooding: When the performers use a lot of sliders vigorously, something hangs. The technician says that Opendeck has to be restarted. (I'm not 100% what is happening, because he says the same has happened at some point when using a Moog One as a controller. Is it not the MIDI data receiver that needs to be reset?) I'm waiting for more detailed info on this.

However:

1. If it is the Opendeck L Board that is hanging, would it still be possible to restart L Board from the USB C / web interface? The reason I'm asking is that the technician needs to be able to reset L Board mid-performance if it hangs.

2. Ideally he would be able to reset L Board via a MIDI command, not using a browser

3. Being a hardware / software developer I would prefer to have a Hardware Reset pin exposed on the L Board, to which I could connect a hardware switch, possibly controlled by a transistor and a separate MIDI interface, or by a long cable

4. If the problem is not that the L Board chokes, but that it sends too much data and the receiver data buffer is flooded, then it would be nice to have a way to limit the data rate / amount of midi bytes per second that is sent from L Board

Thanks,
Andreas

[paradajz]

The latest customer has a problem with what I think is MIDI data flooding: When the performers use a lot of sliders vigorously, something hangs.

What is "something"?

he says the same has happened at some point when using a Moog One as a controller. Is it not the MIDI data receiver that needs to be reset?) I'm waiting for more detailed info on this.

Yeah not really the OpenDeck problem then. The test would be to perform the same amount of slider moving while connected to the PC or to other hardware synth or whatever. I have never experienced the hanging problem so it's not likely an OpenDeck problem, but again, it could be something.

What is the OpenDeck board connected to and via what? USB or DIN MIDI?

1. If it is the Opendeck L Board that is hanging, would it still be possible to restart L Board from the USB C / web interface?
2. Ideally he would be able to reset L Board via a MIDI command, not using a browser

Yes. https://github.com/shanteacontrols/OpenDeck/wiki/SysEx-Configuration#reboot

3. Being a hardware / software developer I would prefer to have a Hardware Reset pin exposed on the L Board, to which I could connect a hardware switch, possibly controlled by a transistor and a separate MIDI interface, or by a long cable

Yeah but that would just mask the problem - it's not a solution.

4. If the problem is not that the L Board chokes, but that it sends too much data and the receiver data buffer is flooded, then it would be nice to have a way to limit the data rate / amount of midi bytes per second that is sent from L Board

There are no limits for now. I will think about this.

[9bit-se]

Sorry for the delay, the band has been playing so didn't get back to me until now.

Here's the additional information you asked for (however their tech person will do more testing on Wednesday, in 2 days)

What is "something"?

It seems to be Opendeck L that is hanging

Moog One

Yeah not really the OpenDeck problem then.

I'm sorry, this was a red herring, it's totally unrelated to what's happening with Opendeck. Moog One hanged when they sent a lot of midi data to it (by jumping to different locations in the Ableton project) However no Moog is used, and no midi data is sent from Ableton to Opendeck in the current setup.

What is the OpenDeck board connected to and via what? USB or DIN MIDI?

Opendeck is connected to an Iconnectivity Mio XM via USB-C. The Mio XM is then connected to Mac + Ableton via Ethernet / RTP-midi. There's also to a number of other controllers and synths connected to Mio XM via USB-1 and DIN midi, and from there, RTP-midi to the computer. My understanding is that no synth is controlled directly by Opendeck -> Mio XM -> synth; instead everything goes through the Mac / Ableton and back to the synths. I'm not 100% sure about that.

Their tech person said, when it hangs the other controllers keep sending and receiving data to / from the computer. So Mio XM and Mac seem to still work. If Opendeck is power-cycled by removing the USB-C cable, everything goes back to normal.

What remains to be explored is what stops working

1. Opendeck midi output *
2. Opendeck midi input + output
3. The slider scanning / ADC data processing that hangs and midi still works *
4. The USB-C link between Opendeck and Mio XM, but on the Mio XM side
5. Something else that I haven't thought of

*If so, it would be possible to reset Opendeck with the SySex command, from the Mac. Thanks for the pointer :)

I have another Opendeck L in the workshop, I'll try and connect 8 sliders to it and see if I can replicate the problem, when connected with USB-C directly to my Mac.

I will know more on Wednesday

All the best
/ Andreas

[paradajz]

Thanks for getting back. Definitely keep me updated.

[9bit-se]

I've done some testing with Opendeck L and 8 sliders, directly connected to a Mac USB-C input. I used MIDI Monitor to analyze data on the Mac.

I haven't really discovered anything, just trying to narrow down a bit. I have not been able to make anything hang; neither midi over USB-C connection, the Mac or Opendeck L.

Opendeck seems to work as expected, it doesn't send any invalid data according to MIDI Monitor. Opendeck seems to be in SysEx configuration = ON mode by default, so it did send some (slider ID) Sysex information every 20 CC messages or so. I guess it's unlikely that the SysEx would confuse Mio XM but I'll tell the tech person to turn it of with F0 00 53 43 00 00 00 F7

At this point I have two general questions that I'm sure you're able to answer :)

1. I have been researching the data rate of midi over USB, but the answers have been conflicting so far. Generic USB 1 / 2 data rate is much higher than DIN midi. But I'm still unsure wether a) the midi signal on each midi port within the USB signal is still 31.25 kbps, and the higher capacity of USB is only used for stacking more ports into one USB cable. Or b) if the actual data rate of the midi itself is higher in USB than in DIN midi. (I'm still thinking that a serial buffer somewhere might be flooding.)

2. Depending on the answer to 1) would there be any advantage to assign a different midi channel to each slider? Probably not, but if I could assign individual (virtual) midi ports to sliders, then the total maximum data rate would be higher?

Grasping for straws, waiting for tech person to do some tests

/ Andreas

[paradajz]

Opendeck seems to work as expected, it doesn't send any invalid data according to MIDI Monitor.

This is expected. :)

Opendeck seems to be in SysEx configuration = ON mode by default

It is not, the SysEx mode activates only once you open the configuration utility or if your explicitly enable the SysEx configuration by sending the handshake message.

https://github.com/shanteacontrols/OpenDeck/wiki/SysEx-Configuration#handshake-request

1. I have been researching the data rate of midi over USB, but the answers have been conflicting so far. Generic USB 1 / 2 data rate is much higher than DIN midi.

Yes. In fact, MIDI throughput via USB isn't limited at all, which was one of the main points of creating USB MIDI spec in the first place.

a) the midi signal on each midi port within the USB signal is still 31.25 kbps

Not sure what do you mean. If you have a device accepting USB MIDI data which then transfers it via DIN, then yes, DIN is always limited to 31.25k, so it's up to the device doing the conversion to have large enough buffer for the incoming USB data. The other way it can be implemented is to simply not ACK received USB message (always required by the spec) until the outgoing DIN MIDI buffer is free to receive more data, and I have a hunch that this is what is happening. The OpenDeck board sends tons of data, the incoming buffer on your device gets filled, the OpenDeck doesn't receive ACK for some time and then possibly something fails on my end - possibly a panic of some sort - I am using 3rd party USB stack so I would need to investigate.

[9bit-se]

SysEx mode activates only once you open the configuration utility

I see. That's what I do for every Opendeck board I use, so I guess I got the feeling that SysEx mode was on by default

Not sure what do you mean

Your previous paragraph already answered, and what you wrote about the device that converts from USB to DIN midi has the responsibility to limit data density explained further :)

While I don't have experience nor utilities to debug USB transmissions, I think what you wrote is easily understandable. Is there anything I can do to help gather information about this? Maybe I could install something and do some basic testing with Opendeck - Mio XM - Mac?

However, now that I think about it: In this case the signal is not converted to DIN midi. It's Opendeck L (USB-C) -> (USB in) Mio XM (RTP-midi out) -> (RTP-midi in) Mac.

/ A

[paradajz]

Maybe I could install something and do some basic testing with Opendeck - Mio XM - Mac?

If you have XM then you can do the same test as you did, just with the XM in between and see if the board stops responding.

However, now that I think about it: In this case the signal is not converted to DIN midi. It's Opendeck L (USB-C) -> (USB in) Mio XM (RTP-midi out) -> (RTP-midi in) Mac.

Doesn't matter - it's a different transport mechanism so everything I wrote still applies. You always need buffers in between.

[9bit-se]

The band has down prioritized this, possibly since it's working with "normal use". However, it seems we're to build another copy of the same rig, so I'll get a Mio XM then, and I will get back about this then :)