KingKorg sysex dump format specs?

[Narioso]

Hi
Are Korg secrative over this - or is there one?

I remember finding for CX-3v2 when I needed it.

If there is a standard in how Korg do 8 bit binary as in Cx-3, 7 7-bit bytes and 8th is keeping 7 top bits for those 7 bytes.

Are all Korgs doing it this way?

Then once having true 8-bit binary - to have offset specs for all locations?

Thanks.
Best regards

[OpAmp]

Hi,

Get it at the support site of Korg.
http://i.korg.com/SupportPage.aspx?productid=654

Bye.

[Narioso]

Thanks, but there is no such system exclusive spec there.

One of manuals state basic sysex command header and a way to set volume or tune the unit. Nothing else.

So even a proper sysex command of everything is missing.

As I did with Hammonds you had very good help from sysex commands as such to identify the bits and bytes in sysex dump.

I will have a look inside kklib file as a start.

What I am trying to figure out is if there is a byte telling how many program are in each category. Since there knob for picking next in a category is just referring to next patch numbers, not next in category.

From start there is 35 in synth, before Lead category start. So slot 1-35 if fixed to Synth category. If I eventually find I have 50 in synth category I have not found a way to fix that Lead start at 51 instead.

And there is different number of slots for each category, but if replacing stock programs with what you actually use you want to assign this.

As an example I changed program 001 to have category Strings. So when I press Synth I always get program 001, and Strings button light up. The turn knob and program 002 is Synth again making that light up.

I see no use of catgories unless you can fix this. It's like time ran out for devs when about to release KingKorg. And no firmware updates fixed it either, as it seems.

So bottom line, if I get 50 that I consider Synth category, 20 Lead, and whatever on the rest - I'd like to rewrite all my programs but be able to get a starting point for each category and just use knob to get next in category.

This is my attempt since Korg obviously abandoned KingKorg.

If they fixed a browse mode for knob to pick next program in same category chosen, disregarding program number - I would be all happy.
You press Brass and always get the first program number that has Brass category. Turn knob or press Brass again and next program with Brass is activated even if program slot 242.

It's anything but smooth as it is now.
The only downside with KingKorg for me - stunning unit that encourage creativity.

I suspect there is a byte in the sysex dump that tells each category which tells first program slot and last or similar for each category.

Maybe there is a sysex command that let you set this to liking.

I'm pretty sure there are more people feeling the same way as I do.

[OpAmp]

On the page I refer, there is the following document:
http://i.korg.com/uploads/Support/USA_K ... IDIImp.txt
which is what you're looking for.
It is ascii and a lot of tables, but pretty complete at first sight. Just dropped a quick look into it: there is a byte per program, indicating the type/category.

I see something in the global section. You can store 8 program numbers for the categories. My educated guess is that this specifies the program number you jump to when pressing the category number. It is up to the user to make a consistent set then, i.e. from that number you store only brass till the program number for the following category. The byte in the program is only to choose which button that will light up.

But I don't own a KK, so I can not confirm this.

Have fun.

[Narioso]

On the page I refer, there is the following document:
http://i.korg.com/uploads/Support/USA_K ... IDIImp.txt
which is what you're looking for.
It is ascii and a lot of tables, but pretty complete at first sight. Just dropped a quick look into it: there is a byte per program, indicating the type/category.

I see something in the global section. You can store 8 program numbers for the categories. My educated guess is that this specifies the program number you jump to when pressing the category number. It is up to the user to make a consistent set then, i.e. from that number you store only brass till the program number for the following category. The byte in the program is only to choose which button that will light up.

But I don't own a KK, so I can not confirm this.

Have fun.

Thanks a lot, and excuse my poor investigation.
In my defense I downloaded a pdf with midiimp in name yesterday, and stopped reading further. That was only one page with basics.

You might have solved it all for me, thanks again.

[Narioso]

Offset data in spec is not quite right though.

Looking at spec, I wondered how values up to 299 could be set in one byte.
And as it turns out there are two bytes for each.

Starting at binary offset 134-229 are represented by 8x2 byte entries where each category starts in program number. Then the five banks of 8x2 bytes each representing program number that is favourite.

Default it looks like this:

converted to binary first row, default dump format below

Code: Select all

      synth lead  bass  brass strin piano key   se/voice
-- -- 00 00 00 23 00 43 00 5F 00 6C 00 88 00 97 00 B0

bb -- 00 00 00 23 00 43 20 00 5F 00 6C 00 08 00 05 17 00 30
xx                      xx                      xx

xx marks bytes where high order bits have to be edited if using values larger than 127 direct in global sysex dump.

The crucial parts are solved for me though, the rest I can do manually.

Eventually I will make a utility that sorts programs in total sysex dump according to category and also changes start position for each button to be correct.

[OpAmp]

Hi,

Yes you are right. I did not remark that while glancing through the doc. You can not represent a 0-299 in one byte. It must be done by spreading over 2 bytes. So the documentation is not completely correct... Good you figured it out.

The thing that you explain about the MSB (bit 7 of a byte) is the 'normal' way Korg and others use to send binary data over SysEx. They split the data in groups of 7 bytes and strip off the MSB of each byte. The MSBs itself are then collected in an extra byte that is send before the 7 (stripped) bytes. This is explained /pictured in some way in note 3 of the document. Note that offsets in the tables typically refer to the bare binary data, before it is converted to MIDI data. So you could opt to write a conversion between bare data (without the SysEx headers) and MIDI sysex (and vice versa).

Bye.

[Narioso]

Thanks again.

I did some utitlities for CX-3v2 I had, to write all percussion and leslie data to all presets. Just cumbersome redoing that every patch.
(I posted some 3-4 years ago at KVR I think it was with source code and all. Simple command line utility for windows)

Just reused some conversions for KingKorg.

Now that offset positions are identified one can go right away on sysex bytes and patch those. Korg does not use checksum, so no problem doing that.

Thanks for your attention and sharp eyes seing the specs I missed.

[michelkeijzers]

I thought that the KingKorg uses the .kklib file format.
Or are normal system exclusive MIDI dumps also used? If so, can someone give me a link to such midi files?

Maybe I can add support for PCG Tools, I always thought .kklib was the only format and that format is quite different from what PCG Tools supports.

[OpAmp]

The KingKorg Sound Librarian uses the .kklib file format to store programs on a disk. It is the only file format the librarian supports. The file contains the programs in a kind of encrypted and/or compressed format.

However when a program is sent/retrieved from the KK, it uses (obviously) MIDI SysEx messages. The format of these messages is described in the document for which I posted earlier in this thread the link. The librarian converts the programs back and forth between the .kklib file format and the more readable/normal MIDI SysEx message when sending/receiving programs over MIDI.

==

(I don't own a KK, but I tricked the librarian to make it think it is connected to a KK and I could retrieve the SysEx for a patch. It seems at first sight in line with the description in the documentation, the name of the patch can clearly be seen, which is not the case in the .kklib file I started from. I used the .kklib file containing the factory defaults.) I think it may be hard to figure out the .kklib format, but it should still be possible to integrate a 'librarian functionality' in the PCG Tools for the KK, where you store the programs in a different format than the .kklib format on disk.

Bye.

[michelkeijzers]

The KingKorg Sound Librarian uses the .kklib file format to store programs on a disk. It is the only file format the librarian supports. The file contains the programs in a kind of encrypted and/or compressed format.

However when a program is sent/retrieved from the KK, it uses (obviously) MIDI SysEx messages. The format of these messages is described in the document for which I posted earlier in this thread the link. The librarian converts the programs back and forth between the .kklib file format and the more readable/normal MIDI SysEx message when sending/receiving programs over MIDI.

==

(I don't own a KK, but I tricked the librarian to make it think it is connected to a KK and I could retrieve the SysEx for a patch. It seems at first sight in line with the description in the documentation, the name of the patch can clearly be seen, which is not the case in the .kklib file I started from. I used the .kklib file containing the factory defaults.) I think it may be hard to figure out the .kklib format, but it should still be possible to integrate a 'librarian functionality' in the PCG Tools for the KK, where you store the programs in a different format than the .kklib format on disk.

Bye.

PCG Tools would serve best if it supports the kklib format since that format is used by most users. I have a reasonable idea about the format though. However, it has an extra 'layer' around it, so it would cost quite some effort to implement that (since PCG Tools has a lot of re-usable code).

However, if in the future default MIDI system exclusive info is used, that would make it more easy.

[michelkeijzers]

Hi
Are Korg secrative over this - or is there one?

I remember finding for CX-3v2 when I needed it.

If there is a standard in how Korg do 8 bit binary as in Cx-3, 7 7-bit bytes and 8th is keeping 7 top bits for those 7 bytes.

Are all Korgs doing it this way?

Then once having true 8-bit binary - to have offset specs for all locations?

Thanks.
Best regards

No, only the older types, I think until around the Trinity.