bug - Take 5 - some patches never get loaded from Orm on PC

[AJMur]

Bug - on windows 10 with version 1.13.4 with Sequential Take 5, on clicking on Orm Library screen, some (apparently random) patches never get loaded to synth. Orm doesn't report an error e.g. this patch never loads:
18:09:50: Sending patch Bells Of Bronze to Sequential Take 5

Synth screen stays stuck on "Receiving Sysex..." but continues playing the previous patch, until another patch gets sent successfully. The same patches never load, i.e. if a patch (e.g. Bells Of Bronze) doesn't load once, that same patch will never load on retry later.

[christofmuc]

@AJMur Thank you for reporting this! It would be great to get the MIDI log for this. Can you check if the MIDI log after the hanging screen, and upload here?

The patches that don't load, were they loaded from disk or imported fro,m the synth and now can not be sent back into the synth?

[AJMur]

Will do asap. They were loaded from synth and now can't be sent back.

[AJMur]

00:54:03.211: Out Take5 Sysex [f0 01 35 03 0c 02 02 3c 36 02 02 54 00 54 00 00 01 01 00 00 00 00 00 00 00 00 00 00 00 02 02 43 43 00 3f 22 00 00 75 00 00 00 00 7f 00 00 00 00 7f 7f 7f 7f 00 7f 00 00 00 02 40 00 00 28 00 03 00 00 01 01 08 13 28 48 1b 28 00 00 03 07 06 7f 7f 00 00 00 00 00 03 00 00 00 00 01 40 00 00 00 00 00 00 7e 00 7f 7f 00 00 00 23 00 00 00 31 1d 1d 2d 7f 7f 00 00 10 10 00 00 00 00 00 00 00 00 00 0a 09 00 00 00 00 00 00 00 00 00 40 00 00 00 00 00 00 13 01 13 7f 7f 7f 7f 7f 7f 00 7f 7f 7f 7f 7f 7f 7f 00 7f 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0f 1d 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 60 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 54 00 35 20 50 6c 61 79 73 00 20 49 74 20 43 6f 6f 00 6c 20 20 20 20 00 00 00 00 00 02 00 00 04 01 00 00 00 00 00 00 13 00 00 40 64 22 38 22 18 22 78 38 2a 0f 7f 7f 7f 7f 7f 7f 7f 7f 7f 7f 7f 7f 7f 7f 7f 7f 7f 7f 7f 7f 7f 7f 7f 7f 7f 7f 7f 7f 7f 7f 7f 7f 7f 7f 7f 7f 40 11 1c 03 0c 11 1c 01 00 0f 11 1c 03 0c 11 1c 01 01 0f 11 1c 03 0c 11 02 1c 01 0f 11 1c 03 0c 04 11 1c 01 0f 11 1c 03 08 0c 11 1c 01 0f 35 3c 00 30 29 1d 3c 33 30 29 00 30 35 3c 3c 30 30 35 00 29 3c 30 33 35 3c 30 00 33 37 35 30 3c 3c 2d 00 30 35 27 3c 30 33 35 00 3c 30 37 33 2e 27 3c 00 3c 3c 33 35 33 3c 35 00 3c 30 3c 33 37 3c 3c 00 3c 33 41 37 27 22 0f 00 64 16 01 01 64 27 01 00 01 16 27 64 64 36 46 00 01 06 64 42 6d 05 64 00 0b 44 05 14 0f 64 64 00 01 12 1c 01 64 3c 5e 00 4d 64 21 20 32 5e 01 00 64 64 64 3f 2c 4d 64 00 0a 64 20 64 01 01 64 00 64 64 01 01 3d 2a 1a 00 3c 3c 3c 3c 3c 3c 3c 00 3c 3c 3c 3c 3c 3c 3c 00 3c 3c 3c 3c 3c 3c 3c 00 3c 3c 3c 3c 3c 3c 3c 00 3c 3c 3c 3c 3c 3c 3c 00 3c 3c 3c 3c 3c 3c 3c 00 3c 3c 3c 3c 3c 3c 3c 00 3c 3c 3c 3c 3c 3c 3c 00 3c 3c 3c 3c 3c 3c 3c 00 3c 64 64 64 64 64 64 00 64 64 64 64 64 64 64 00 64 64 64 64 64 64 64 00 64 64 64 64 64 64 64 00 64 64 64 64 64 64 64 00 64 64 64 64 64 64 64 00 64 64 64 64 64 64 64 00 64 64 64 64 64 64 64 00 64 64 64 64 64 64 64 00 64 64 3c 3c 3c 3c 3c 00 3c 3c 3c 3c 3c 3c 3c 00 3c 3c 3c 3c 3c 3c 3c 00 3c 3c 3c 3c 3c 3c 3c 00 3c 3c 3c 3c 3c 3c 3c 00 3c 3c 3c 3c 3c 3c 3c 00 3c 3c 3c 3c 3c 3c 3c 00 3c 3c 3c 3c 3c 3c 3c 00 3c 3c 3c 3c 3c 3c 3c 00 3c 3c 3c 64 64 64 64 00 64 64 64 64 64 64 64 00 64 64 64 64 64 64 64 00 64 64 64 64 64 64 64 00 64 64 64 64 64 64 64 00 64 64 64 64 64 64 64 00 64 64 64 64 64 64 64 00 64 64 64 64 64 64 64 00 64 64 64 64 64 64 64 00 64 64 64 64 3c 3c 3c 00 3c 3c 3c 3c 3c 3c 3c 00 3c 3c 3c 3c 3c 3c 3c 00 3c 3c 3c 3c 3c 3c 3c 00 3c 3c 3c 3c 3c 3c 3c 00 3c 3c 3c 3c 3c 3c 3c 00 3c 3c 3c 3c 3c 3c 3c 00 3c 3c 3c 3c 3c 3c 3c 00 3c 3c 3c 3c 3c 3c 3c 00 3c 3c 3c 3c 3c 64 64 00 64 64 64 64 64 64 64 00 64 64 64 64 64 64 64 00 64 64 64 64 64 64 64 00 64 64 64 64 64 64 64 00 64 64 64 64 64 64 64 00 64 64 64 64 64 64 64 00 64 64 64 64 64 64 64 00 64 64 64 64 64 64 64 00 64 64 64 64 64 64 3c 00 3c 3c 3c 3c 3c 3c 3c 00 3c 3c 3c 3c 3c 3c 3c 00 3c 3c 3c 3c 3c 3c 3c 00 3c 3c 3c 3c 3c 3c 3c 00 3c 3c 3c 3c 3c 3c 3c 00 3c 3c 3c 3c 3c 3c 3c 00 3c 3c 3c... (4095 more bytes)]

[AJMur]

that's the midi log from a hanging/failed patch send ^^

[christofmuc]

@AJMur Thank you! Hm, the log is truncating the MIDI patch, but what is telling is of course (I forgot) that the Take 5 patches are so large, larger than 4 KBytes.

Interesting would be if the patch is always failing or if it can be successfully transferred if it is tried multiple times?

Next test could be to send the sysex with a different program, to rule out that the MIDI transfer inside the Orm is causing this. If you search for the exact name of the patch with the text search, you get a grid that displays only this one patch. You can then press Export to Sysex to create a syx file with just one patch. That could be transferred to the synth e.g. using Midi-OX (Windows) or Sysex Librarian (Mac) - if this works, we know the problem is not in the data but in the transfer, and vice versa.

[christofmuc]

@AJMur Sorry, read your initial report again and you already stated that repeated retries won't fix it, so trying to send the same data with another program like MIDI-Ox is probably a good test.

[AJMur]

I don't have IDI-Ox but can try that.

If it helps, a successful patch send also is truncated, if that's what "....(4095 more bytes)]" at end of midi log means.

[christofmuc]

@AJMur Yes, the printout of the log does not want to spit out that many bytes, as the Take 5 patches are rather large due to the polyphonic sequencer. It would be useful to try to send the same data with another program, so we can figure out if the MIDI message is incorrect, or there is a problem with the large MIDI transfer, or it is a bug in the KnobKraft Orm.

[christofmuc]

Closing with not enough information to proceed. I don't have a Take 5 to test this myself :-/

[delamorte]

Sorry for opening this old issue, but I've been running into this bug lately with Take 5, but only on Linux (Arch, KnobKraft 2.2.3.1 compiled from latest master). I can import patches from the synth fine, but trying to load any patch from KnobKraft to the Take 5 results in the stuck synth screen "Receiving SysEx..", while there are no errors on Knobkraft side.

I have Windows 11 installed on the same PC, and with Windows I can send patches from KnobKraft to Take 5 normally. On Linux I also tested with the amidi command line utility, and I could send patches exported from KnobKraft normally, so that would indicate a problem with KnobKraft.

I created logs from sending the same patch with Windows/Linux, but they both look identical (both are truncated at the same place).

Is there any more info I could give to help debug this?

take5-sysex-send-windows.log
take5-sysex-send-linux.log

[christofmuc]

Very strange. It seems that both programs want to send the same bytes, and actually do so by handing it over to the JUCE libraries sendMessage function.

Let's assume Linux MIDI uses ALSA.

Looking the source from the sendMessageNow() in juce_Midi_linux.cpp, it seems there is no upper limit of message size - but the message would be broken apart into multiple blocks in case ALSA wants to. But the blocks are immediately relayed to the "Sequencer", which for ALSA seems to also be the output device.

Googling, this seems to be a frequent issue with Linux MIDI and ALSA, e.g.

• ALSA and JACK do not support large SysEx messages thestk/rtmidi#214
• how to handle very long sysex messages davidmoreno/rtpmidid#93
• Send large sysex by chunks to bypass faulty midi interface drivers asb2m10/dexed#157
• https://forum.electra.one/t/command-line-preset-file-upload-tool/592/16

Sadly, the JUCE library even swallows error messages from the Linux send code instead of logging or reporting it.

it seems for Linux, we'd need to drop JUCE. We're on JUCE 7.0.6, and I did not see anything in the release log https://github.com/juce-framework/JUCE/releases that indicates they are willing to touch the Linux MIDI code. I'll open a new issue for the large sysex on Linux topic because this is probably not Take 5 specific. Thanks for reporting!