shooking
commented
3 years ago And now I realise, after writing my own ZD2 parser, you already did most of what I do with your construct and Python.
Just incase you are interested it is also possible to pull out the parameter names directly from the ZD2.
/*
** OK so we look for
** 54 58 45 31 == TXE1
** 4f 6e 4f 66 66 == OnOff (later we try to work out a vector to this offset)
** 50 52 4d 4a == PRMJ - like PRME but with binary data
** 50 52 4d 45 == PRME - more readable form
*/I am pretty sure the PRMJ is Japanese and E is English. Why?
Infile: ZNR.ZD2
Filesize: 26307
INPUT
FX: ZNR
VERSION: 1.30
Mungewell's ID
01 00 00 40
FXID: 64(0040) FXGID: 8(0008)
...
PRMJstart = 61f3( 25075)
"Parameters":[
{
"name":"DETCT",
"explanation":"制御信号の検出位置を選択します。",
"blackback":false,
"pedal":false
},
{
"name":"Depth",
"explanation":"ノイズリダクションの深さを設定します。",
"blackback":false,
"pedal":false
},
{
"name":"THRSH",
"explanation":"効果が現れる閾値を調節します。",
"blackback":false,
"pedal":false
},
{
"name":"Decay",
"explanation":"減衰時間を調節します。",
"blackback":false,
"pedal":false
}
]
PRMEstart = 6470( 25712)
"Parameters":[
{
"name":"DETCT",
"explanation":"Sets control signal detection level.",
"blackback":false,
"pedal":false
},
{
"name":"Depth",
"explanation":"Sets the depth of noise reduction.",
"blackback":false,
"pedal":false
},
{
"name":"THRSH",
"explanation":"Adjusts the effect sensitivity.",
"blackback":false,
"pedal":false
},
{
"name":"Decay",
"explanation":"Adjust the envelope release.",
"blackback":false,
"pedal":false
}
]Not sure if you already done this but I also managed to pull out the bitmaps. Write from hex 88 offset to bitmap file size [[there is a BM at 0x88, the header is standard bitmap]]. The size is int from bytes 0x8a - 0x8d (fileSize in struct below)
typedef struct t_bmHeader {
BYTE signature[2];
BYTE fileSize[4];
BYTE reserved[4];
BYTE dataOffset[4];
} bmHeader;
typedef struct t_bmInfoHeader {
BYTE size[4];
BYTE width[4];
BYTE height[4];
BYTE planes[2];
BYTE bitsPerPixel[2];
BYTE compression[4];
BYTE imageSize[4];
BYTE xPixelsPerM[4];
BYTE yPixelsPerM[4];
BYTE coloursUsed[4];
BYTE importantColours[4];
} bmInfoHeader;
typedef struct t_bmColourTable{
BYTE red;
BYTE green;
BYTE blue;
BYTE reserved;
} bmColourTable;
need 2 of the above colour .. one for white, one for black.I am almost there with the decode now. Thanks for all your tips. Now to write it in Lua for Ctrlr.
mungewell
Hi Mungewell
I managed to find some time to revisit the Zoom pedals recently - your decode preset was super useful. C, inspite of its lovely low level bit operators, caused me no end of grief with bit arrays, packing and struct alignment.
Anyhow in your excellent work you find IDs like:
It's taken me an age to realise this can be interpreted as two shorts that store hints on the FXID and GID. So your ID can also be viewed as GID x 32 (first short) and FXID (2nd short).
I am sure you already know this - just incase others are not aware. Likely it is some misaligned bit pattern.
What is not so clear. On some FX the slot is 2 wide (we know this but I not yet managed to find from the preset alone). I think the decode_screens knows this right?
But I was able to then set "7" FX on a single preset :-). Now it is only 5, but well a bit odd. And this is somewhat non-deterministic. So I can get the 7th slot to add an FX sometimes, not others.
I used this program to drive it.
I generated the decode of the patch. Then deleted - notice I then had to adjust the slot IDs for my code.
Original state:
So sometimes FXM_Delete.sh 7 actually deletes slot 1. Quite literally odd.