Patch files - PPRM block

[mungewell]

I have started to decode the PPRM block, and have located the patch volume, but don't know what any of the other bits/bytes might represent... any suggestions? https://github.com/mungewell/zoom-zt2/blob/master/decode_preset.py#L56

[mungewell]

The bits before the patch volume are reported as unknown key and (at least for the GCE-3) there is little variation.

simon@thevoid:/media/simon/OS/Users/simon/Documents/ZoomFW/GCE-3_v1.20_Win_E/unzipped/.rsrc/1041/BIN/extract_zptc$ cat *.dump | grep -e "PPRM" -A 5 | grep "unknown" | sort | uniq -c
    168                 unknown = 12816
     25                 unknown = 17185
      5                 unknown = 21554
      2                 unknown = 25923

And in binary...

>>> "{0:029b}".format(12816)
'00000000000000011001000010000'
>>> "{0:029b}".format(17185)
'00000000000000100001100100001'
>>> "{0:029b}".format(21554)
'00000000000000101010000110010'
>>> "{0:029b}".format(25923)
'00000000000000110010101000011'

[mungewell]

Looking at those with '25923', there are 2 patches.

52992.zptc.dump:                unknown = 25923 => u'StringGt  '
53728.zptc.dump:                unknown = 25923 => u'Rezo Cln  '

[shooking]

Hi @mungewell I am tied up next week - broke me Burny LP55s (dropped) and was patching it back together. Anyhow next weekend I will try to catch up with what you are doing. My approach would be to write out the known patch params, then see which ones are missing. See if varying them modifies that area. But I guess you are already doing this?

What I notice from the older G5 is one could set pedal parameters. We believe the PRME is the PaRMeter in English right? The JSON we generate tells us what parameters there are? So wouldnt the PPRM have the PaRMater Midi values??

So would we expect any hidden stuff in there (other than maybe a checksum?).

Like I said on the older pedals one can set, in the patch, what the control in pedal will control. And the expression pedal - the G1XFour etc is more verbose than the earlier pedals. For example the description (which I havent found a sysex for - dont think I have). You hinted it is possible to load patches between eachother on the newer pedals? So maybe there is more info in the PPRM block?

[mungewell]

I made progress in writing patches to pedal types that they didn't come from... actual when padded to the correct size they pedal accepts and corrects some things. https://github.com/mungewell/zoom-zt2/issues/40

You mentioned G1XFour, and now mine is back in reach I tried a few tests on that...

# output commands to read all patches from pedal
  
for patch in range(10,60):
    print("python3 ../../zoomzt2.py -p %d patch%d.ztpc" % (patch, patch))

And then..

$ python3 grab_all.py > grab_all.sh
$ bash grab_all.sh
$ find . -name '*.ztpc' -exec bash -c "python3 ../../decode_preset.py -d {} > {}.dump" \;
$ cat *.dump | grep -e "PPRM" -A 5 | grep "unknown" | sort | uniq -c
     15                 unknown = 0
      8                 unknown = 1
      2                 unknown = 1074
      1                 unknown = 12816
      2                 unknown = 17185
      4                 unknown = 2
      9                 unknown = 3
      9                 unknown = 4

>>> "{0:029b}".format(1074)
'00000000000000000010000110010'
>>> "{0:029b}".format(12816)
'00000000000000011001000010000'
>>> "{0:029b}".format(17185)
'00000000000000100001100100001'

Will dig into whether there is a noticable commonality of the patches with the same lower bits for unknown.

[mungewell]

Didn't see any parameter/feature of the patch which would explain these bits, however I did note that they are automatically reset (to their 'normal' value) if I deliberately change and then reload the adjusted patch. ie they mean something to the pedal, they aren't just unused values.

$ python3 ../../decode_preset.py -d test.ztpc | grep -A 10 "PPRM"
    PPRM = Container: 
        length = 12
        autorev = b'\x00\x00\x002\x00\x00\x00\x00\x00\x00\x00\x00' (total 12)
        reversed = Container: 
            control = Container: 
                punknown = 0
                volume = 100
                pad = 0
            unknown = b'\x00\x00\x00\x00\x00\x00\x00' (total 7)
$ python3 ../../zoomzt2.py -P 50 test.ztpc 
$ python3 ../../zoomzt2.py -p 50 test2.ztpc 
$ python3 ../../decode_preset.py -d test2.ztpc | grep -A 10 "PPRM"
    PPRM = Container: 
        length = 12
        autorev = b'\x00\x0c\x842\x00\x00\x00\x00\x00\x00\x00\x00' (total 12)
        reversed = Container: 
            control = Container: 
                punknown = 12816 <------------ reset to previous value
                volume = 100
                pad = 0
            unknown = b'\x00\x00\x00\x00\x00\x00\x00' (total 7)

I don't think that they are a checksum, as they do not change if the name or order of effects are changed within the patch.

[shooking]

Very kindy. So PPRM is parameter block for an FX. I wonder - if you make a patch with say 5 identical FX do these values remain same in each FX?

I was going to suggest changing FX order in a patch with different FX but like we know the PPRM is per FX.

We don't have any FX where the version has been updated? And are the unknown bits the same regardless of patch? IE if it can be seen to be constant then it's some sort of signature or fixed attribute (I guess).

[mungewell]

Just for clarity the PPRM block is NOT for individual effects, it is overall setting for the patch ('.ztpc' file). We know it contains the patch volume (different from individual effect's volume).

[mungewell]

On the question of ZD2 effects which have changed/have different versions. I made a list of the ones offered via GL... https://github.com/mungewell/zoom-zt2/blob/master/zoom_fx/master.txt

I can run through all the ones I have extracted from FW images to see if there's any which are different from the above...

[shooking]

Thanks for the clarification. I guess you have some candidates.

0x02000051 : Gt GEQ (v1.10), 0xab2c491e83f2e755bbf05dd35017286d
0x02000053 : Gt GEQ 7 (v1.10), 0x2ee248d8194055c6adaeeeef113c4b52
0x02000054 : Gt GEQ 7 (v1.10), 0x47afd7dbfc1cfc309f455dba1f36207a
0x02000060 : St Gt GEQ (v1.10), 0x149879b7fb183f6df9f67aae90fc6382
0x02000061 : St Gt GEQ (v1.10), 

I wonder if they generate different PPRM when put in a patch (inplace of eachother)

[mungewell]

These two... are actually the 2screen (G3n/etc) and 1screen versions (G1Four/etc).

0x02000050 : Gt GEQ (v1.10), 0x46d90b7a39c68c95d256a07e4a57ba13
0x02000051 : Gt GEQ (v1.10), 0xab2c491e83f2e755bbf05dd35017286d

They have different filenames and 2screen versions are blocked on the G1Four with GUARD.ZT2. Don't know what happens if you bypass that protection... https://github.com/mungewell/zoom-zt2/blob/master/zoom_fx/G3n/unzipped/list_sorted.txt#L15 https://github.com/mungewell/zoom-zt2/blob/master/zoom_fx/G1%20FOUR/unzipped/list_sorted.txt#L15

I'll be looking for ZD2 with exactly the same ID and different (embedded) version numbers.

[mungewell]

Wow, there were way more that I expected - for example:

0x01000010 : Comp (v1.10), 0x4fa7a52bc19e7e5152c11284bc7e23ad
0x01000010 : Comp (v1.20), 0xef9f226550c8ff0456043fa32b144f96
0x01000010 : Comp (v1.30), 0xed47bb3a16fb16d537c4a1e105520a47
0x01000010 : Comp (v1.40), 0x734b3be53622c6d6930775fca9089301

uniq.txt

[mungewell]

Another interesting observation, if I upload a complete set of patches and then download again all the 'punkown' values (in PPRM) are low numbers (ie <=4).

When I edit/save a patch on the pedal, then then number becomes high. Note I have auto-save turned off. For example 'MonkeyRCT' starts as 1, but becomes 17185 ('00000000000000100001100100001')

[mungewell]

Figured out a few more bits - the lower 3 bits are the slot which is currently being edited, these can only be read as 'download current patch' as placing pedal in PC mode clears any unsaved changes.

This also only reports correctly if the pedal is 'edit' phase, where the individual parameters of the effect are shown on the screen. This may be different for the larger pedals.

I've checked in the changes to allow this, command is like... slots labelled 0 through 4 on G1Four.

$ python3 ../../zoomzt2.py -c test.ztpc
$ python3 ~/zoom-zt2-sdw-github/decode_preset.py -d test.ztpc | grep "slot"
                slot = 0

Still have more bits to identify in PPRM, but haven't figured what makes them change.

[shooking]

is there some new code I should pull to play along? I have the G3n and G5n so could see if anything changes.

[mungewell]

I added some stuff to repo in: https://github.com/mungewell/zoom-zt2/blob/master/decode_preset.py

The is a --pad command line to set the size/padding when saving changed files with --output. If you use the --dump command then there is additional information decoded from the files.

Things to check: 'target' - ie which pedal this patch came from. 'pslot' - from the PPRM block, I think this only applies when read 'current patch' (possibly with auto-save turned off).

Still don't know what the unknowns are.....