Preset Sysex Dump Documentation?

[slee]

I created a Max for Live device that can edit my Slim Phatty using MIDI CC. I created a similar device for my Waldorf Blofeld, but with it, I am able to read the current preset using sysex and then adjust the parameters in my Max for Live device with that data. I have been trying to do the same thing with the Slim Phatty, but am having a hard time reading the data. So far I've only been able to set up the easy ones (limited amount of options) like OSC range & Filter Poles but am quite lost in how to get values like Cutoff Filter, ASDR, etc. It involves some MSB LSB magic that I cannot seem to wrap my head around. Does anyone have or know where documentation on the Phatty sysex dumps are?

[denoiser]

This has been asked before; see Opensource editor for SP/LP (was: sysex reverse-engineering)

As Moog officially did not reply, I decided to go my way and make my own preset librarian Phatty. As it is open source, you can see the actual sysex messages used to communicate with the LP and how the preset parameters are stored in the preset sysex messages. However, as it is more a preset management than an editor and it was designed to work in conjunction with the synth, only the menu parameters, preset name and some global parameters are present in the editor; but not the panel parameters, which is your question.

Nonetheless, I took a look at how the cutoff and filter attack parameters are stored in the sysex file and I saw that each of these two parameters need 3 bytes in the sysex file. This is a fragment of the python code in preset.py.

Code: Select all

FILTER_CUTOFF_START_BYTE = 85
FILTER_ATTACK_START_BYTE = 61

def get_12b_bytes(v):
    v = ~(v & 0xfff)
    return [(v & 0xc00) >> 10, (v & 0x3f0) >> 4, v & 0xf]

def get_12b_value(bytes):
    v = (((bytes[0] & 0x3) << 10) | ((bytes[1] & 0x3f) << 4) | (bytes[2] & 0xf))
    return (~v) & 0xfff

The first function returns the 3 bytes stored in the sysex files from the parameter value in the range [0-4095] and the second one does the opposite.
Notice that the start bytes do not consider the F0 byte at the start of the sysex messages.

I hope it will be useful.