After the recent news about the Korg Pandora PX5D USB-Midi working with an upcoming kernel patch, I got interested in making a native linux version of the Sound Editor that Korg offers for download only for Mac and Windows. It runs great in Wine, but I thought there might be some interest in having a native version, and why not, one which could have extended functionnalities (midi program change, continuous controllers for effect parameters...).

It boils down to reverse engineering the windows Sound Editor, and it's a really fun investigation. It's gonna be a lengthy article that I will keep up to date as I progress...

June 3rd, 2011

Understanding the file format

I started to look at the way the editor saves presets. It can save 3 types of files:

• individual sound presets
• all presets in a single file
• all drum machine chain presets in a single file

I first only cared for the individual sound presets. They come as 58-byte files and look like this:

0x00->0x1F : unknown content (mostly 0 bytes, only 4 valus which meaning I don't know yet) 
0x20-0x26 : preset name (it's not ASCII, "A" has value 21, see character table below)
0x27 : module switch (a bit flag signaling which effect modules are enabled)
0x28 : dynamics effect
...
0x39 : Noise reduction level

From offset 28 to 39 we have settings for all effects. Most values go from 0x00 to 0x1E, but some (the delay time for instance) goes to 0x64.

The sequence of allowed characters is not ASCII based, but a subset, where 'A' has index 21. The character map can be found in the manual.

All of this clear now, I've been able to build a preset reader in Java and get all the parameters of a preset in memory.

Monitoring MIDI SysEx

The Pandora and the editor communicate via MIDI SysEx messages. And though it's not recognized as a standard USB-Midi device, it works like one. First, I asked the Pandora it's identity with this SysEx Request Identity message (f07e7f0601f7):

amidi -p hw:3,0,0 -S f07e7f0601f7 -r identityrequest.syx -t 5

which returned this:

f0 7e 00 06 02 42 73  00  20  00  00 00 01 00 f7

The standard response for an Identity Request is of the form: F0 7E cc 06 02 id fc1 fc2 fn1 fn2 v1 v2 v3 v4 F7 where:

cc:  channel
id: device's ID
fc1 fc2  - device's family code
fn1 fn2  - device's family number
v1 v2 v3 v4 - device software ersion

So, for the pandora we have:

channel = 00
device Id = 42
family code = 73 00
device number = 20 00
software version: 0.0.1.0

Then, I started to monitor what the editor sends to the Pandora when you change each parameter of a preset, and was able to list all SysEx commands that change the unit's parameters.

TODO Next

That's a lot already discovered! But a lot remains to be done. First, I need to understand what are the 4145 bytes sent by the Pandora to the editor when it starts (after the identification request). I get the same dump with this command:

amidi -p hw:3,0,0 -S F0423073200FF7 -r dump.syx -t 15

All SysEx commands from the Pandora begin with F042307320, and 0x0F may mean a program dump.

I still have not decoded this file, but I gues the editor identifies the Pandora, and then grabs all it's presets, to be in sync. The pandora must also send the current preset.

Once this is cleared up, I still need to understand the file format that has all the presets in it. But that's not the most important thing.

The big task next will be to understand how to use Alsa to send midi commands to the Pandora, and then decide what library to use for the GUI... probably QT4 and coded in C++, though my current prototypes are in Java.

June 4th, 2011

Finally understood the file format the Windows Sound Editor uses. It was actually pretty simple. Preset files start with a common header:

        0x10, 0x45, 0x00, 0x00,
        0x00, 0x00, 0x00, 0x00,
        0x00, 0x00, 0x00, 0x00,
        0x00, 0x00, 0x00, 0x00

Followed by this one for a single preset file:

        0x20, 0x00, 0x00, 0x01,
        0x00, 0x00, 0x00, 0x00,
        0x00, 0x00, 0x00, 0x00,
        0x00, 0x00, 0x00, 0x00

or this one for a multi-preset file:   
        0x20, 0x00, 0x00, 0x64,
        0x00, 0x00, 0x00, 0x00,
        0x00, 0x00, 0x00, 0x00,
        0x00, 0x00, 0x00, 0x00

This is followed by one ore more preset definition chunks. Actually the 20th byte must be the number of presets in the file (the Pandora has 100 factory presets + 100 user presets).  I can now read and write both formats.

June 5th, 2011

Got it! The SysEx dump command:

amidi -p hw:3,0,0 -S F0423073200FF7 -r dump.syx -t 15

sends all user bank presets, followed by all chain presets (I'll check this but I think you can't edit the factory patterns). The block of data starts with a SysEx header, followed by a compact representation of each preset, identical to their form in the preset files! Only one strange things it seems to have some sort of padding, and zero bytes appears in the dump, but only for sound presets, and apparently not chain presets.

More soon...