Katana MKII: How to decode the sysEx set when the channel is changed

Started by MrKarlos, October 24, 2023, 05:29:13 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.


I am trying to code an iPad editor for my Katana 50 MKII. I have decoded most of the SysEx and can request/decode my own blocks. The challenge I am having is decoding the SysEx messages the Katana sends when the Patch is changed.
It send a short message to with the Patch number it has changed over to. After the short patch number message the Katana sends 7 sysex messages of 255 bytes each. The messages are for the Temporary patch area as the first two bytes of the address are 0x60 0x00 but the 2nd two bytes only make sense on the first message as they map to the start of Patch Name and then the Patch_0 address map.

Has anyone worked out the logic to the address/parameter mapping of these 7 sysex message blocks?


When the Katana is switched to "editor mode" a patch/channel change results in the Katana sending
1: the current patch/channel number (as you have observed).
2: the new channel patch data addressed to the temporary memory address. (60 00 00 00 to 60 00 0F 08) 2156 bytes.
3: sometimes a few other bytes related to the chain order if a non-standard signal chain order is used.

If you require the Katana address map, and you have Tone Studio for Mk2 installed on Windows, look at
C:\Users\your_login.name\AppData\Local\Roland\BOSS TONE STUDIO for KATANA MkII\html\js\config\address_map.js
Free "GR-55 FloorBoard" editor software from https://sourceforge.net/projects/grfloorboard/


thanks @gumtown I have been reverse engineering the address_map.js file.

As each block SysEx block is 241 data bytes but with only one address at the start of each SysEx block, I am starting to work on the assumption that the SysEx data contains a continuous stream of data from the initial address and this stream of data may cover two of more settings blocks e.g. the first 241 midi data bytes will cover the blocks: PatchName, Patch_0, Eq(2), and a chunk of Fx(1) - up to parameter 'PRM_FX1_HARMONIST_V2_HARM_1'.

Do you decode the 255 byte SysEx blocks or do you send out specific requests for each parameter block when you detect a change of channel?


In the FxFloorBoard editor, the incoming data blocks are re-structured into 128 byte addressable ranges.
Mk2 is
60 00 00 00 = 128 bytes
60 00 01 00 = 128 bytes
60 00 02 00 = 128 bytes
60 00 03 00 = 128 bytes
60 00 05 00 = 128 bytes
and so on to
60 00 0F 00 = not so many bytes
or there abouts..

A patch request is sent to encapsulate the entire patch range of data, so only one data request call is made for a patch.

But when the Katana is set to "editor mode" any channel change will automatically cause the Katana to spew out that patch data upon channel selection.

A data block can be requested from any memory address point (4 byte address), and a data block length/size is specified (4 byte block size).

Free "GR-55 FloorBoard" editor software from https://sourceforge.net/projects/grfloorboard/


@gumtown, Thank you for the feedback. I used the same approach as you on the editor I created using touchOSC. It is a way to get a known state of the device.

I'm building an editor for Mac, iPhone and iPads using Swift so I am porting the LUA code from TouchOSC to Swift. Quite a learning curve!

Anyway I have solved the challenge. I have knocked together some python to create a JSON file from the address_map.js file and I load this into my Swift App. I have solved the midi message processing challenge I had by creating a separate Roland Address object. I released that the Katana accesses its memory using a 28 bit byte but this looks like a 32 bit byte when sent over midi.

Thank and thanks to the person that wrote the Go code for the lib-katana project on GitHub. It pushed me in the right direction.