Testing for K5000S on linux

[firstnevyn]

K5000S firmware v4.03 Linux

Midi communications seem.. Broken

Working:
Load from individual sysex files to library for bank A and D
load from individual sysex files to library for multi (entries are created but the data isn't viewable or editable)
Tagging etc..
Master keyboard events

Things that don't work:
Receive a patch dump initiated from the synth
Receive a bank dump initiated from the synth
Retrieve a patch initiated from KnobKraft
Retrieve Bank initiated from KnobKraft
See banks on synth
Load bank from sysex file on disk

[firstnevyn]

when I attempt to access the synth banks directly I get this error.

In the setup tab if I set the synth channel to invalid and click detect it correctly updates it to 16

[markusschloesser]

Ah I got confused as you also posted in the edisyn gh and thought it was about that 😂

[markusschloesser]

Please post logs (ideally set to debug)

[firstnevyn]

Midilog.txt
debuglog.txt
midimonlog.txt

[firstnevyn]

the adaptation definitly thinks it's sending the sysex to the port.. but monitoring midithru.. it's not apparent in anyway.

[christofmuc]

Thanks @firstnevyn for testing this and uploading the logs, and @markusschloesser for the adaptation and your work on the earlier bank issues. We have reviewed the report, screenshot, logs and current adaptation. Since I don't have a K5000 available, would you both be willing to help collect a small set of comparable evidence when you have time? No rush—this would help us investigate without asking you to try speculative fixes.

There seem to be at least two issues worth separating:

• The screenshot shows “Synth not connected”. This check can prevent a bank request from being sent at all. The fact that Detect finds channel 16 is useful; we need to understand what happens between successful detection and opening the bank.
• We reproduced an offline bank-import dependency on detection state in the current adaptation: with a freshly loaded adaptation, the existing K5000R Bank A recording imports 98 patches, but Bank D fails with Invalid bank byte 2. No matching bank found.. Setting the detected model to either K5000S or K5000R lets the same Bank D recording import 40 patches. This is something we can investigate and fix without hardware, although we still need the failing file to establish whether it explains your particular import failure.

The uploaded logs show two outgoing writes of “FM-Piano” to Fast Track Ultra MIDI 1 on channel 16, but no detection or download exchange. The external monitor shows Active Sensing only. That does not yet tell us whether the problem is the selected route, actual transmission, reception, or interpretation of the response.

A first capture from each of you would be very helpful:

1. Please list your exact K5000 variant, firmware, memory expansion if any, KnobKraft version, and MIDI interface. For Linux, please include the distribution and whether any MIDI routing software is involved. Please also attach the actual KawaiK5000.py adaptation you are using, especially if it is a custom copy.
2. Starting from a fresh application launch, enable debug logging, run Detect, and capture the selected MIDI input/output and channel. Does the connection indicator turn green, and does it stay green when you return to the Library and click Bank A? Please save the debug and MIDI logs covering that entire sequence, including the identity request/reply and any error.
3. In a separate capture, request one known occupied program from Bank A and note its number/name. An occupied slot matters because an empty slot may not reply. Please include both the outgoing request and incoming response, if any. A complete binary .syx capture is preferable to truncated hexadecimal text.

@firstnevyn, could you also attach one bank file that fails to import, along with the exact import action/error? If convenient, please try that same file before and after successful detection and tell us whether the result changes.

@markusschloesser, a successful detection and single-program retrieval capture from your Windows setup would give us a valuable reference. Please confirm your exact model too—the repository's existing recordings are labelled K5000R, and we should compare model/firmware/interface as well as operating system.

If the first captures still leave the transport unclear, the next useful comparison would be retrieving that same occupied program with an independent MIDI utility on the Linux machine, using the same physical interface and connections. We need to monitor the actual selected route; absence from a MIDI Thru monitor alone may not establish whether the request reached the synth.

These captures should let us build repeatable tests and replay the responses without owning the hardware, while separating connection-state and parser problems from Linux MIDI transport or model differences. Thank you both for any time you can spare!

[christofmuc]

"We" is "me and Codex", of course.