SysEx STREAM_MAX_SIZE / timeout problem

[m.str]

I was wondering about how the pre-definition of the SysEx STREAM_MAX_SIZE variable (as 128) in mnbg_event.c came about.

The reason I am asking is that I have recurring problem with

[MIOS32_MIDI_Receive_Handler] Timeout on port 0x21

which, as I have found in other posts, means that there is an overflow on MIDI In 2. In my setup this is the "return" port of a hardware synthesizer, that I am controlling with control elements on another MIDI hardware device (bidirectionally connected on MIDI In/Out 1). While switching through various editing modi on device 2 it always sends a SysEx dump of the parameter values currently set in the selected program/patch. I am reading these values with syxdump_pos=x:y, syxdump_pos=x:y+1, ...., syxdump_pos=x:y+n and assigning them each to a control element on device 1. This setup shows me that the SysEx dumps is (always) cut off at syxdump_pos:x:52.

This confuses me, as I can not explain why an overflow, and a subsequent disposal of further incoming bytes, happens so early, since the MAX_SIZE is set to 128... Of course there are probably some additional messages being transferred (like Ack messages for the successfully received dump request etc.), but still this does not make much sense to me.

I tried to cope with this by increasing the STREAM_MAX_SIZE  in mbng_event.c to 256. Same result , though. I can't come up with any other to deal with this I must honestly say. Has anyone else experienced similar problems when handling the transfer of SysEx parameter dumps? I'd love to hear your thoughts about this.

Greetings,

Micha

[Zam]

Hello Micha

Not a direct answer, but some observation at my side.

I'm used to this time out message when in the past I play around with midi baudrate speed (for multicore direct connection in a project)

what is sure is you need same RX/TX speed at both side of the midi wire, I suppose that's not your issue,

but I also notice that wire length can have impact, in other hand the TX/RX quality and potential data lose.

In your case I suppose you have optocoupler, investigating that side of hardware and data integrity might be an option.

Best

Zam

[m.str]

Hello Zam, thanks again for your reply :)

Upon your response I had to do some thinking and looking up.. I mainly tried to figure out a way to check the optocoupler on the jacks of my I/O Board, but I honestly just did not get it. Also been looking for a way to adjust the baudrate (I thought this would probably be implemented in the app.c itself?), also no luck.

The thing I COULD try immediately of course was switching the original cable (5m) for a significantly shorter one (1,5m I guess). I dearly hoped that this could have been the solution, but that was not the case. Still the timeout errors occur on the same commands, just like before.

I guess I have just to have to take it then. A while ago I could make some improvements by injecting some delay_ms commands in the ngr script. Though this is not a desirable solution obviously...

[Zam]

Hello

Baudrate setting is a mios32_uart.h

But you obviously need to change this at both side of the wire, so won't work if you have a hardware synth where you can't change this setting. (31250 is a midi compliance)

Only useful if you hook two midibox devices and you want to gain some data speed/density

 

Have you try to change optocoupler ? I have vague memory to read around some issue with. But don't remember the context.

 

I also notice timeout error in my early mios experimentations when the core is really busy.

like lot of data IO stream, which can be exponential if you have the debug on at the same time

Have you tryed sending/receiving the sysex message with minimal activity around (no other midi message, no event value change, no NGR script runing)

 

Just another guess, but what is the data a your pos 52 ? maybe it's a conflict with some MIOS terminal command ?

 

Best

Zam

 

[m.str]

Hey Zam,

On 30.7.2020 at 2:36 PM, Zam said:

But you obviously need to change this at both side of the wire, so won't work if you have a hardware synth where you can't change this setting. (31250 is a midi compliance)

Okay thanks for the clarity, I see now that this is not applicable to my case, as I am always dealing with hardware synths/controllers on both sides of the configuration chain.

On 30.7.2020 at 2:36 PM, Zam said:

Have you try to change optocoupler ? I have vague memory to read around some issue with. But don't remember the context.

To be honest I do not really trust my own capabilities enough to do this and I kind of have a deadline on my project, so I guess I will have to exclude that idea...

On 30.7.2020 at 2:36 PM, Zam said:

Have you tryed sending/receiving the sysex message with minimal activity around (no other midi message, no event value change, no NGR script runing)

Actually yes. I do have some test scripts, that I use to test knob behaviours on my hardware controller. Those scripts only initialize one or two of the encoders for parameter change and therefore only read one or two positions of the SysEx dump. I do not get the timeout message there. Thing is, I do not think I can reduce the IO load in the actual script, because I set it up in a way (and I am still not sure that this is the optimal way to do it) that everytime a parameter gets changed, a dump request is committed in order to update the display values on my MIDI controller. But now that I think of it, that is another story, because the timeout message occurs also when just starting up the project (without any knob tweaking)

 

On 30.7.2020 at 2:36 PM, Zam said:

Just another guess, but what is the data a your pos 52 ? maybe it's a conflict with some MIOS terminal command ?

Interesting suggestion,  but I am pretty sure the actual data does not collide with any of the MIOS terminal functionalities. Come to think of it, the terminal messages are always introduced by a different SysEx Header ..

static const u8 sysex_header[5] = { 0xf0, 0x00, 0x00, 0x7e, 0x50 };

..taken out of the mbng_sysex.c file. This is why I do not think there is a collision, I hope I did not misunderstand anything there. The message for the 52nd value includes an ordinary byte value encapsuled in the same SysEx stream as the other values form the dump are, hence my assumption.

Thanks again for sharing your thoughts with me on this issue, I appreciate it!