USBHost sysex with CME Widi Bud

#1

Sorry for the vague question. I've been messing about with sending sysex to my Roli Seaboard Block the last couple of days. When I load a patch, I send three sysex messages using MidiSendSysex(), each 16 bytes long (to set midi channel start/end + MPE on/off). With the CME Widi Bud (for bluetooth midi) I get a ring buffer overflow if I send all three at once, but a delay between each fixes that.

Everything behaves as expected with an USB cable, but with the Widi Bud only the first sysex message works. So whenever a new patch is loaded, the first sysex message works (it doesn't matter which it is), the next ones doesn't. If I keep sending messages after that while the patch is running, some works, some don't, without any obvious pattern.

So, realizing that the Widi Bud is probably to blame here, not Axoloti, what I was hoping for was that someone with a better understanding of what goes on on a low level might have a clue what is causing this. Or, since the first message on a freshly loaded patch consistently works, is there some way to "reset" the USBHost back to that state? So that I could do reset - sysex - reset - sysex - reset - sysex for a reliable transfer?

#2

this should not happen, there is room on the ring buffer for 64x4 bytes midi messages, so your 3 x 16 bytes would only take a tiny fraction of this - so thats a 'concern', perhaps you are mixing other midi data in the stream?

there is no way to reset the usb host, and i don't think that would work anyway, as this would mean the device initialisation would be done again... i.e. the thing your sending too, what probably act as a disconnect/connect, so require all the MPE messages again.

unfortunately debugging usb really requires a usb protocol analyser, and they are not cheap...
you could possibly get a bit more info if you debug the axoloti kernel, but having done this before, its unlikely to throw up much.

the next release of axoloti will have a completely new usb stack, based on chibios rather than stms framework.

#3

The Seaboard block sends a 11 byte sysex msg twice every second or so, but that is the only other midi I know of. The overflow is only when using the Widi Bud, not with an USB cable, so that is probably the culprit, somehow. The whole thing bugs me a bit simply because I don't see the logic to it. But I don't actually need to get it working, so I'll leave it at this for the time being. I was just experimenting to see what I can expect to be able to do with the Roli Blocks and Axoloti.

Out of curiosity, does the new release/usb stack change anything regarding sysex messages?

#4

these are not processed, and do not go on the output queue (so no overflow msg)

my suspicion is that for some reason the output queue is not being read at all... but if you don't retry, I don't understand why the queue would overflow... unless what is happening is you are assuming the messages are processed, and then continuing to send other midi messages i.e. its not really anything to do with the sysex.... what happens if you don't send the sysex messages at all? do other midi message get thru?

yes, its all changing... and is the reason usb hub will work, obviously the flipside, is that as all the code is new, we don't have the experience with the quantity of devices we did with the old code, , though we have tested the devices we have, and they generally look ok, and have helped highlight a few issues, but we will only know for sure, when its released and others test their devices.
(of course, we are assuming, and hopeful that most devices will work perfectly ok)

one change, which I need to get some time to do, is to allow for receiving/processing of sysex... but been a bit busy with other things.