Send large sysex by chunks to bypass faulty midi interface drivers

[Sentinel77]

Hi,

'Send current sysex cartridge to DX7' is not working on Linux.
It works on Windows. Maybe someone can also test on Mac.

With my testing it seems that Linux is having a hard time sending a large single buffer of 4104 bytes.

Recieving a cartridge from the DX7 to Dexed works fine. Single voices send ok also.

I did a test with KMidimon to monitor the midi through connector on the DX7 as Dexed tries to send a cartridge.
This loopback test showed that only 3840 bytes looped back.
So the Linux system is not transmitting the full 4104 bytes.

If I capture a cartridge from the DX7 using KMidimon, it shows that Linux seems to be splitting the 4104 sysex into 256 byte buffers.
I can then use KMidimon to play back this capture to the DX7 and it successfully transfers the sysex cartridge to the DX7.

So a possible solution would be if Dexed can send the cartridge in 2 or more smaller buffers, rather than one large one.

I am using the Roland UM-ONE MK2, and I also tried with a generic usb midi interface.

[asb2m10]

I had this issue on Windows also. To make it work on any computer, I recommend using the M-Audio Midi Uno (it is in the FAQ). The Uno driver and the device is a little more "clever" and does the buffering.

We could buffer it, but we need to put this on another thread to avoid locking the UI. I wonder what is the correct burst size to avoid issue... I will check to see how this is handle elsewhere.

[asb2m10]

I have a Roland UM-ONE ; I will check if I see the same behavior with my Mac and keep you posted.

[eeferg]

I too am unable to send patches and I am using the Roland UM-ONE. I have the option to set the MIDI input device but there is no section to select MIDI out.

[Sentinel77]

Click on the PARM button for DX7 Out.

[eeferg]

Ahhh. That was it. I can confirm that the Roland UM-ONE cable works when pushing patches to a TX7, using the Windows build.

[asb2m10]

Well, I have the UM-ONE and I have the issue on Linux and macOS. The issue is in the USB to MIDI protocol (somewhat). That's why some (like M-Audio) implemented their own. Maybe if I tried to installed the Roland drivers (and not the Midi generic ones) I would not have the issue on Windows for the UM-ONE.

For now, stick with interfaces that are known to work.

In the future we could send this by chunk (256bytes per 30 ms?) to bypass the driver bug, but this needs to be truly tested.

[shooking]

Well, I have the UM-ONE and I have the issue on Linux and macOS. The issue is in the USB to MIDI protocol (somewhat). That's why some (like M-Audio) implemented their own. Maybe if I tried to installed the Roland drivers (and not the Midi generic ones) I would not have the issue on Windows for the UM-ONE.

For now, stick with interfaces that are known to work.

In the future we could send this by chunk (256bytes per 30 ms?) to bypass the driver bug, but this needs to be truly tested.

I think midi on Linux, at least ALSA, internally buffers at 256. It isn't unique to Dexed - Ctrlr and other programs hit this when receiving data from outside world. As you say, some hardware is likely coping with this better.

I debugged down into the JUCE layer recently for a Raspberry Pi ported Ctrlr issue. Drove me nuts. I then tried my panel on Windows. Worked perfectly fort time. So I moved my panel to Ubuntu x64 - same issue as Pi port. In my case I was able to request file blocks of 128 bytes rather than 512 (is for a Zoom pedal).

All I am.trying to say is JUCE itself has lots of issues on Linux. Ctrlr, a 3rd party Juce app, in same was that Dexed is, just seems to drop the odd 256 buffer and that is a similar amount to what was reported.
The app works find on Windows, same hardware, but not Linux. BUT rtmidi via Python can seemingly work.