Mind the Gap - Katana sysex bulk 255 bytes - on patch change

[JeamPierre]

Hello all members of this epic forum,

/*
Here is my short story to put my question in perspective
I have a katana mkII, i had time to spare & wanted a programming challenge. After reading discussions here on this forum, i decided to reinvent the wheel and make my own version of a library that enables communication between the amp and a teensy 4.1. (The goal here is mainly programming for fun, make a versatile midi controller for myself, and share my experience when done.)

So my code is not turned into a library yet, but everything i wanted works fine. Thanks to the documentation on this forum, i followed along and made a system that can ask and set values for all parameters, one at a time or by bulks, all is good. I have lists of parameters names to be printed on oleds later, I double checked my values using BTS, really, i'm thrilled!
*/

I'm replicating communication based on what BTS does. So on startup, (for the "temp" channel)
- ask for ID (and wait for KT to respond)
- set COM_MODE to 1
- ask for PATCH_NAME (and wait for KT to respond) (for each channel)

- then ask by bunch for bytes for each parameter (72 bytes from ODDS address, 128 bytes from FX1_SW address, ... and so on (number of bytes asked matches the sysex table/map i found around here so all is good, all matches) >> https://www.vguitarforums.com/smf/index.php?topic=27749.msg201458#msg201458 )

SO here we come to the weirdness i encountered, and i don't know what to make of:

At this stage, if i ask for parameters values by small bunch, avoiding the "gaps" in the table all works fine (for exemple between 0x60000057 and 0x60000100, there is a gap of 168 bytes that i suppose unused, empty/full of unwanted data, and i guessed i should disregarded)

But BTS does not seem to mind the gap when asking for 91bytes from "REV_SW" (0x60000540) when all i can see are 50bytes of used data (up to "MASTER_KEY" 0x60000571) // i know there's "chain" stuff right at 0x60000600 but still, what of the gap? What are those 41 bytes difference?

Things got worse for my theories when changing patch. Here, the amp gets you data by bulks of 255 bytes. So of course, until the first gap i'm fine, but thing seems to get out of alignment later on. Maybe there's useful bytes that i disregarded? Maybe these are unaccounted for padding bytes? Really i'm perplex.

A really simple solution will be to ask again with my working method anytime i change patch but it feels stupid.

So would anyone have an idea of the system used by the amp when it sends 255 bytes ? Are there parameters missing from the lists that would explain the misalignment? Does anyone have any clue on this?

Cheers to all, thank you for this forum anyways, i really enjoyed my time around here.

[JeamPierre]

At any given time, i always hesitate before posting on a forum. Weeks i have been trying to figure this out.
Now i have posted, i have the solution (well i guess i do)

>> i have the MKII and those unaccounted for bytes were not shown in my reference. Because i was looking at an old MKI adress_map.js....

now i feel silly.

I'm modifing things in light of that crucial information... i'm sure it will do the trick. Furhermore, there are other sys gnrl eq i did not now about. I'll do the math but i'll find these matches my misalignment of values for sure.

Thank you anyways. I'm still working on it but i'll share as soon (or if) i have something working worth posting here.

Take care

[MrKarlos]

Hi @JeamPierre

Did you find the cause of the gaps? It may be a result of not counting in 7 bits. The 4 Roland address bytes are 7 bit bytes so they only go up to 0x7F.

e.g. 0x7f + 1 = 0x100