Open mungewell opened 2 months ago
There are also some differences in the GroupName
, although I am not too sure how these affect the actual operation. Maybe just used for ZT2 and grouping of ZIC in the library (MS-plus).
B1 FOUR/unzipped$ find . -name "*.ZD2.dump" -exec grep groupname {} \; | sort | uniq
groupname = u'AMP' (total 3)
groupname = u'CABINET' (total 7)
groupname = u'DELAY' (total 5)
groupname = u'DRIVE' (total 5)
groupname = u'DYNAMICS' (total 8)
groupname = u'FILTER' (total 6)
groupname = u'MODULATION' (total 10)
groupname = u'REVERB' (total 6)
groupname = u'SFX' (total 3)
ms-60b/decoded$ find . -name "*.ZD2.txt" -exec grep groupname {} \; | sort | uniq groupname = 'BASS AMP' (total 8)
groupname = 'DELAY' (total 5)
groupname = 'DRIVE' (total 5)
groupname = 'DYNAMICS' (total 8)
groupname = 'FILTER' (total 6)
groupname = 'MODULATION' (total 10)
groupname = 'PITCH SHIFT' (total 11)
groupname = 'PREAMP' (total 6)
groupname = 'REVERB' (total 6)
groupname = 'SFX' (total 3)
groupname = 'SYNTH' (total 5)
I just added some options which might help us...
$ python3 decode_effect.py --help
...
--force-id FORCE_ID Force the ID to a particular value (in Hex)
--force-name FORCE_NAME
Force the Name to a particular string (max 11 chars)
--force-gname FORCE_GNAME
Force the GroupName to a particular string (max 11 chars)
-o OUTPUT, --output OUTPUT
output combined result to FILE
Something like :-)
$ python3 ../decode_effect.py --force-id 0x07000010 -o MOD_BOMBER.ZD2 MS_BOMBER.ZD2
Checksum Recalculated: 0x9966b592
$ python3 ../decode_effect.py -s MOD_BOMBER.ZD2
0x07000010 : MOD_BOMBER.ZD2, Bomber (v1.10 8.45%)
Attempting to install MS effect on my (broken screen) G1Four...
$ python3 ../zoomzt2.py -U BOMBER.ZD2
Uninstalling effect: BOMBER.ZD2
$ cp MOD_BOMBER.ZD2 BOMBER.ZD2
$ python3 ../zoomzt2.py -I BOMBER.ZD2
Installing effect: BOMBER.ZD2
uploading...
$ python3 ../zoomzt2.py -R -w -s FLST_SEQ.ZT2
Group 1 : DYNAMICS
0x01000010 : COMP.ZD2, (v1.40 1)
...
Group 7 : SFX
0x07000020 : AUTOPAN.ZD2, (v1.40 1)
0x07000041 : LPROLL3S.ZD2, (v1.10 1)
0x07000050 : HOTSPICE.ZD2, (v1.30 1)
0x07000010 : BOMBER.ZD2, (v1.10 1)
...
The real question is whether I can actual load it into a patch, which is a little more difficult with the broken screen.
Current patch is empty
$ amidi -p hw:2,0,0 -S 'F0 52 00 6e 64 02 00 09 00 F7' -r temp.bin -t 2
1023 bytes read
$ python3 ../decode_screens.py temp.bin
---
Effect: Bypass (Off)
:
:
:
:
---
Effect: Bypass (Off)
...
Convert ID to 7-bit hex
>>> a = 0x07000010
>>> print(hex(a & 0x7f))
0x10
>>> print(hex(a >> 7 & 0x7f))
0x0
>>> print(hex(a >> 14 & 0x7f))
0x0
>>> print(hex(a >> 21 & 0x7f))
0x38
>>> print(hex(a >> 28 & 0x7f))
0x0
and install to current patch (slot 0)
$ amidi -p hw:2,0,0 -S 'f0 52 00 6e 64 03 00 00 01 10 00 00 38 00 f7'
Decode screens changes, but does NOT display the name
$ python3 ../decode_screens.py temp.bin | head
---
Effect: (Off)
:
:
:
:
---
Effect: Bypass (Off)
...
Downloading current patch does however
$ python3 ../zoomzt2.py -c temp.zptc
$ python3 ../decode_preset.py -s temp.zptc
Name: Empty
Patch Volume: 100
Effect 1: 0x07000010
Enabled: True
Param 1: 0
Param 2: 0
Param 3: 0
Param 4: 0
Param 5: 0
Param 6: 0
Param 7: 0
Param 8: 0
If i revert the effect to the B1Four version, it does show on 'screens'.
$ python3 ../zoomzt2.py -U BOMBER.ZD2
Uninstalling effect: BOMBER.ZD2
$ cp B1_BOMBER.ZD2 BOMBER.ZD2
$ python3 ../zoomzt2.py -I BOMBER.ZD2
Installing effect: BOMBER.ZD2
uploading...
$ amidi -p hw:2,0,0 -S 'F0 52 00 6e 64 02 00 09 00 F7' -r temp.bin -t 2
1023 bytes read
$ python3 ../decode_screens.py temp.bin | head
---
Effect: Bomber (Off)
Decay : 50
Tone : 4
Mix : 30
ON/OFF : TRGGR
---
Effect: Bypass (Off)
:
:
This at least means the pedal is not 'broken' by uploading the wrong/MS-plus version.
Note: when forcing the ID, we only changes the number in the header of the ZD2, nothing within the Code segment as altered.
Alternate approach, take the Code from the MS effect and jam it into B1 effect file. This means that all the other segments are 'as-was'...
$ python3 ../decode_effect.py -D MS_BOMBER.ZD2 -C -o MOD_BOMBER.ZD2 B1_BOMBER.ZD2
Checksum Recalculated: 0x438fb019
$ python3 ../decode_effect.py -s MOD_BOMBER.ZD2
0x07000010 : MOD_BOMBER.ZD2, Bomber (v1.50 8.45%)
$ python3 ../zoomzt2.py -U BOMBER.ZD2
Uninstalling effect: BOMBER.ZD2
$ cp MOD_BOMBER.ZD2 BOMBER.ZD2
$ python3 ../zoomzt2.py -I BOMBER.ZD2
Installing effect: BOMBER.ZD2
uploading...
$ python3 ../zoomzt2.py -R -w -s FLST_SEQ.ZT2 | grep -A 5 SFX
Group 7 : SFX
0x07000020 : AUTOPAN.ZD2, (v1.40 1)
0x07000041 : LPROLL3S.ZD2, (v1.10 1)
0x07000050 : HOTSPICE.ZD2, (v1.30 1)
0x07000010 : BOMBER.ZD2, (v1.50 1)
Group 8 : DELAY
'Screens' works, and it even makes sound when triggered...
$ amidi -p hw:2,0,0 -S 'F0 52 00 6e 64 02 00 09 00 F7' -r temp.bin -t 2
1023 bytes read
simon@the-void:~/zoom-zt2-sdw-github/MS_vs_B1Four$ python3 ../decode_screens.py temp.bin | head
---
Effect: Bomber (Off)
Decay : 50
Tone : 4
Mix : 30
ON/OFF : TRIGGER
---
Effect: Bypass (Off)
:
:
Now I am doubting myself, did I screw up process or trick myself?
$ md5sum *BOMBER.ZD2
ee15a464cc57161677ca42387c6085f4 B1_BOMBER.ZD2
5c6196b5e155841a44c193f291ac4061 BOMBER.ZD2
5c6196b5e155841a44c193f291ac4061 MOD_BOMBER.ZD2
c0743e090025b1bbd919ad9f3133fdef MS_BOMBER.ZD2
And a fresh download from pedal
check$ md5sum *.ZD2
5c6196b5e155841a44c193f291ac4061 BOMBER.ZD2
And I even power cycled pedal to confirm that it does/still works after.... it did!
So does this mean that there's something OTHER than the Code segment that's preventing it working?
There's not too much different; first 'ZDLF' segment and the 'final bytes'... I can quickly rule out the final bytes.
$ python3 ../decode_effect.py -D MS_BOMBER.ZD2 -C -F -o MOD_BOMBER.ZD2 B1_BOMBER.ZD2
Checksum Recalculated: 0x438fb019
$ python3 ../zoomzt2.py -U BOMBER.ZD2
Uninstalling effect: BOMBER.ZD2
$ cp MOD_BOMBER.ZD2 BOMBER.ZD2
$ python3 ../zoomzt2.py -I BOMBER.ZD2
Installing effect: BOMBER.ZD2
uploading...
$ python3 ../zoomzt2.py -R -w -s FLST_SEQ.ZT2 | grep -A 5 SFX
Group 7 : SFX
0x07000020 : AUTOPAN.ZD2, (v1.40 1)
0x07000041 : LPROLL3S.ZD2, (v1.10 1)
0x07000050 : HOTSPICE.ZD2, (v1.30 1)
0x07000010 : BOMBER.ZD2, (v1.50 1)
Group 8 : DELAY
$ amidi -p hw:2,0,0 -S 'F0 52 00 6e 64 02 00 09 00 F7' -r temp.bin -t 2
1023 bytes read
$ python3 ../decode_screens.py temp.bin | head
---
Effect: Bomber (Off)
Decay : 50
Tone : 4
Mix : 30
ON/OFF : TRIGGER
---
Effect: Bypass (Off)
:
:
So it seems that's its the first segment, which isn't fully parsed by my scripts:
So it looks like the Byte (or ULint32) after the checksum is a 'target pedal'... changing 0xA0 to 0x07 lets the original effect (with altered ID) run on the G1Four.
$ python3 ../decode_effect.py --force-id 0x07000010 -o MOD_BOMBER.ZD2 MS_BOMBER.ZD2
Checksum Recalculated: 0x9966b592
$ hexedit MOD_BOMBER.ZD2
$ python3 ../zoomzt2.py -U BOMBER.ZD2
Uninstalling effect: BOMBER.ZD2
$ cp MOD_BOMBER.ZD2 BOMBER.ZD2
$ python3 ../zoomzt2.py -I BOMBER.ZD2
Installing effect: BOMBER.ZD2
uploading...
$ amidi -p hw:2,0,0 -S 'F0 52 00 6e 64 02 00 09 00 F7' -r temp.bin -t 2
1023 bytes read
$ python3 ../decode_screens.py temp.bin | head
---
Effect: Bomber (Off)
Decay : 50
Tone : 4
Mix : 30
ON/OFF : TRIGGER
---
Effect: Bypass (Off)
:
:
check$ hexdump -C BOMBER.ZD2 | head
00000000 5a 44 4c 46 78 00 00 00 92 b5 66 99 07 00 00 00 |ZDLFx.....f.....|
00000010 00 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 |................|
00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000030 00 00 00 00 00 00 00 00 80 00 00 00 00 00 00 00 |................|
00000040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000050 00 00 00 00 00 00 00 00 01 31 2e 31 30 00 00 07 |.........1.10...|
00000060 10 00 00 07 42 6f 6d 62 65 72 00 00 39 b6 11 53 |....Bomber..9..S|
00000070 46 58 00 30 00 00 00 f1 b1 59 ff e5 00 00 00 00 |FX.0.....Y......|
00000080 49 43 4f 4e b6 00 00 00 42 4d b6 00 00 00 00 00 |ICON....BM......|
00000090 00 00 3e 00 00 00 28 00 00 00 18 00 00 00 1e 00 |..>...(.........|
Scripted
$ python3 ../decode_effect.py --force-target 0x07 --force-id 0x07000010 -o MOD_BOMBER.ZD2 MS_BOMBER.ZD2
Whole process repeated for MS-plus' ZNR effect
$ python3 ../decode_effect.py --force-target 0x07 --force-id 0x01000040 -o MOD_ZNR.ZD2 MS_ZNR.ZD2
Checksum Recalculated: 0x37a89eee
$ python3 ../decode_effect.py -7 -s MOD_ZNR.ZD2
0x01000040 : MOD_ZNR.ZD2, ZNR (v1.10 4.35%)
40 00 00 08 00
$ python3 ../zoomzt2.py -U ZNR.ZD2
Uninstalling effect: ZNR.ZD2
$ cp MOD_ZNR.ZD2 ZNR.ZD2
$ python3 ../zoomzt2.py -I ZNR.ZD2
Installing effect: ZNR.ZD2
uploading...
$ amidi -p hw:2,0,0 -S 'f0 52 00 6e 64 03 00 01 01 40 00 00 08 00 f7'
$ amidi -p hw:2,0,0 -S 'F0 52 00 6e 64 02 00 09 00 F7' -r temp.bin -t 2
1023 bytes read
$ python3 ../decode_screens.py temp.bin | head -n 15
---
Effect: Bomber (Off)
Decay : 50
Tone : 4
Mix : 30
ON/OFF : TRIGGER
---
Effect: ZNR (On)
Detect : EFXIN
Depth : 100
THRSHLD : 30
Decay : 0
---
Effect: Bypass (Off)
:
Freaking Awesome!
Did you get the MS+ ZNR effect to run on your G1Four? :-o
Yes, after adaption both MS-plus BOMBER and ZNR ran on my G1Four - it's screen is broken so a little awkward to control...
@thammer I'd be interested what value the MS-75CRD+ and MS-50+ use for the 'target' byte
./OPTCOMP.ZD2
00000000 5a 44 4c 46 78 00 00 00 90 97 bf 62 a0 00 00 00 |ZDLFx......b....|
^^
./MINIMARK.ZD2
00000000 5a 44 4c 46 78 00 00 00 c0 7e 45 47 80 00 00 00 |ZDLFx....~EG....|
I believe that this is a bit field, and the effects for a single pedal seem to have overlapping values. ie the true value for MS-60B+ is 0x80 and 0xA0 overlaps this.
@thammer
Since you have the MS-50G+ and MS-70CDR+, can you please do a summary ('-s -m') print of the effects on each?
Like https://github.com/mungewell/zoom-zt2/blob/master/zoom_fx_ms-plus/ms-60b/effects_sort.txt
Here are the summaries for MS-50G+ and MS-70CDR+. ms50gp_effects_sort.txt ms70cdrp_effects_sort.txt
Yes, after adaption both MS-plus BOMBER and ZNR ran on my G1Four - it's screen is broken so a little awkward to control...
@thammer I'd be interested what value the MS-75CRD+ and MS-50+ use for the 'target' byte
Here are the first 16 bytes from OPTCOMP.ZD2 from the MS-70CDR+:
5A 44 4C 46 78 00 00 00 81 32 AF 3D 90 00 00 00
... and this is the start of VIBRATO.ZD2 from the MS-50G+:
5A 44 4C 46 78 00 00 00 EF DF 14 57 90 00 00 00
Thanks for the sorted lists, I've uploaded. Looks like IDs between MS-50G+ and MS-70CDR+ roughly match, but there is major 'collision' with MS-60B+ ID's... maybe this is deliberate to make sharing effects (as pedals/patches would be confused with duplicate IDs).
Here are all the ZD2 effects the GL7 knows about. I think that if this 'target' is a bit-field, it may be of required capability (more memory, double screen, expression pedal) rather than particular pedal model. None of these bits overlaps the MS-plus values...
$ find "A1 FOUR" -name "*.ZD2" -exec bash -c "hexdump -C '{}' | head -n1 | cut -c 48-60" \; | sort | uniq
02 00 00 00
03 00 00 00
06 00 00 00
07 00 00 00
$ find "A1X FOUR" -name "*.ZD2" -exec bash -c "hexdump -C '{}' | head -n1 | cut -c 48-60" \; | sort | uniq
02 00 00 00
03 00 00 00
06 00 00 00
07 00 00 00
0f 00 00 00
$ find "B1 FOUR" -name "*.ZD2" -exec bash -c "hexdump -C '{}' | head -n1 | cut -c 48-60" \; | sort | uniq
02 00 00 00
03 00 00 00
06 00 00 00
07 00 00 00
$ find "B1X FOUR" -name "*.ZD2" -exec bash -c "hexdump -C '{}' | head -n1 | cut -c 48-60" \; | sort | uniq
02 00 00 00
03 00 00 00
06 00 00 00
07 00 00 00
0f 00 00 00
$ find "B3n" -name "*.ZD2" -exec bash -c "hexdump -C '{}' | head -n1 | cut -c 48-60" \; | sort | uniq
01 00 00 00
03 00 00 00
05 00 00 00
07 00 00 00
0f 00 00 00
$ find "B6" -name "*.ZD2" -exec bash -c "hexdump -C '{}' | head -n1 | cut -c 48-60" \; | sort | uniq
08 00 00 00
0f 00 00 00
$ find "G11" -name "*.ZD2" -exec bash -c "hexdump -C '{}' | head -n1 | cut -c 48-60" \; | sort | uniq
04 00 00 00
05 00 00 00
07 00 00 00
0f 00 00 00
$ find "G1 FOUR" -name "*.ZD2" -exec bash -c "hexdump -C '{}' | head -n1 | cut -c 48-60" \; | sort | uniq
02 00 00 00
06 00 00 00
07 00 00 00
$ find "G1X FOUR" -name "*.ZD2" -exec bash -c "hexdump -C '{}' | head -n1 | cut -c 48-60" \; | sort | uniq
02 00 00 00
06 00 00 00
07 00 00 00
0f 00 00 00
$ find "G3n" -name "*.ZD2" -exec bash -c "hexdump -C '{}' | head -n1 | cut -c 48-60" \; | sort | uniq
01 00 00 00
05 00 00 00
07 00 00 00
0f 00 00 00
$ find "G3Xn" -name "*.ZD2" -exec bash -c "hexdump -C '{}' | head -n1 | cut -c 48-60" \; | sort | uniq
01 00 00 00
05 00 00 00
07 00 00 00
0f 00 00 00
$ find "G5n" -name "*.ZD2" -exec bash -c "hexdump -C '{}' | head -n1 | cut -c 48-60" \; | sort | uniq
01 00 00 00
05 00 00 00
07 00 00 00
0f 00 00 00
$ find "G6" -name "*.ZD2" -exec bash -c "hexdump -C '{}' | head -n1 | cut -c 48-60" \; | sort | uniq
04 00 00 00
05 00 00 00
06 00 00 00
07 00 00 00
0f 00 00 00
$ find "H8" -name "*.ZD2" -exec bash -c "hexdump -C '{}' | head -n1 | cut -c 48-60" \; | sort | uniq
02 00 00 00
03 00 00 00
06 00 00 00
07 00 00 00
$ find "R20" -name "*.ZD2" -exec bash -c "hexdump -C '{}' | head -n1 | cut -c 48-60" \; | sort | uniq
02 00 00 00
03 00 00 00
06 00 00 00
07 00 00 00
For example does '0x08' (in 0x0f) mean that the effect requires an expression pedal?
'0x0F' seems specifically for 'OUT_VP', other PDL effects are '0x07'
$ find "." -name "*.ZD2.dump" -exec grep -H "target = 15" {} \;
./A1X FOUR/unzipped/OUT_VP.ZD2.dump: target = 15
./G1X FOUR/unzipped/OUT_VP.ZD2.dump: target = 15
./G11/unzipped/OUT_VP.ZD2.dump: target = 15
./B1X FOUR/unzipped/OUT_VP.ZD2.dump: target = 15
./G3n/unzipped/OUT_VP.ZD2.dump: target = 15
./B3n/unzipped/OUT_VP.ZD2.dump: target = 15
./G6/unzipped/OUT_VP.ZD2.dump: target = 15
./B6/unzipped/OUT_VP.ZD2.dump: target = 15
./G5n/unzipped/OUT_VP.ZD2.dump: target = 15
./G3Xn/unzipped/OUT_VP.ZD2.dump: target = 15
'0x04' is only for G6/G11, so likely the AU output or maybe some other high-capability
$ find "." -name "*.ZD2.dump" -exec grep -H "target = 4" {} \;
./G11/unzipped/AG750_AU.ZD2.dump: target = 4
./G11/unzipped/SVT_AU.ZD2.dump: target = 4
./G11/unzipped/MUDDY.ZD2.dump: target = 4
./G11/unzipped/7_HEAVEN.ZD2.dump: target = 4
./G11/unzipped/XTSBL_AU.ZD2.dump: target = 4
./G11/unzipped/MACH30AU.ZD2.dump: target = 4
./G11/unzipped/MS1959AU.ZD2.dump: target = 4
./G11/unzipped/UK30A_AU.ZD2.dump: target = 4
./G11/unzipped/MS800_AU.ZD2.dump: target = 4
./G11/unzipped/BGMK3_AU.ZD2.dump: target = 4
./G11/unzipped/DZ_DRVAU.ZD2.dump: target = 4
./G11/unzipped/HW100_AU.ZD2.dump: target = 4
./G11/unzipped/FDBMANAU.ZD2.dump: target = 4
./G11/unzipped/VELVET.ZD2.dump: target = 4
./G11/unzipped/KRAMPUS.ZD2.dump: target = 4
./G11/unzipped/RCTORGAU.ZD2.dump: target = 4
./G11/unzipped/BGMK1_AU.ZD2.dump: target = 4
./G11/unzipped/MS45OSAU.ZD2.dump: target = 4
./G11/unzipped/ORG120AU.ZD2.dump: target = 4
./G11/unzipped/FDDLXRAU.ZD2.dump: target = 4
./G11/unzipped/POLLEX.ZD2.dump: target = 4
./G11/unzipped/REDLOOM.ZD2.dump: target = 4
./G11/unzipped/FDMSTRAU.ZD2.dump: target = 4
./G11/unzipped/FD_TWRAU.ZD2.dump: target = 4
./G6/unzipped/MUDDY.ZD2.dump: target = 4
./G6/unzipped/7_HEAVEN.ZD2.dump: target = 4
./G6/unzipped/XTSBL_AU.ZD2.dump: target = 4
./G6/unzipped/MACH30AU.ZD2.dump: target = 4
./G6/unzipped/MS1959AU.ZD2.dump: target = 4
./G6/unzipped/UK30A_AU.ZD2.dump: target = 4
./G6/unzipped/MS800_AU.ZD2.dump: target = 4
./G6/unzipped/RDCBST1U.ZD2.dump: target = 4
./G6/unzipped/EGFLTR1U.ZD2.dump: target = 4
./G6/unzipped/KKFLNG1U.ZD2.dump: target = 4
./G6/unzipped/BGMK3_AU.ZD2.dump: target = 4
./G6/unzipped/DZ_DRVAU.ZD2.dump: target = 4
./G6/unzipped/HW100_AU.ZD2.dump: target = 4
./G6/unzipped/FDBMANAU.ZD2.dump: target = 4
./G6/unzipped/VELVET.ZD2.dump: target = 4
./G6/unzipped/KRAMPUS.ZD2.dump: target = 4
./G6/unzipped/RCTORGAU.ZD2.dump: target = 4
./G6/unzipped/SPCHOL1U.ZD2.dump: target = 4
./G6/unzipped/BGMK1_AU.ZD2.dump: target = 4
./G6/unzipped/TS_BST1U.ZD2.dump: target = 4
./G6/unzipped/HLDDLY1U.ZD2.dump: target = 4
./G6/unzipped/MS45OSAU.ZD2.dump: target = 4
./G6/unzipped/HLDVRB1U.ZD2.dump: target = 4
./G6/unzipped/ORG120AU.ZD2.dump: target = 4
./G6/unzipped/FDDLXRAU.ZD2.dump: target = 4
./G6/unzipped/POLLEX.ZD2.dump: target = 4
./G6/unzipped/REDLOOM.ZD2.dump: target = 4
./G6/unzipped/FDMSTRAU.ZD2.dump: target = 4
./G6/unzipped/FD_TWRAU.ZD2.dump: target = 4
You can call me crazy... but I went for it....
Preparing Icon
$ cp ../BLANK.ZIC AUTOPAN.ZIC
$ python3 ../convert_zic.py AUTOPAN.ZIC
Converting: AUTOPAN.ZIC
Writing: icon_0.png
Writing: icon_1.png
$ gimp icon*
$ python3 ../convert_zic.py -r AUTOPAN.ZIC
Converting: AUTOPAN.ZIC
Preparing and uploading AUTOPAN (from the G1Four selection)
$ python3 ../decode_effect.py -s G1Four_AUTOPAN.ZD2
0x07000020 : G1Four_AUTOPAN.ZD2, AutoPan (v1.40 4.10%)
$ python3 ../decode_effect.py --force-target 0xa0 --force-id 0x09000050 -o AUTOPAN.ZD2 G1Four_AUTOPAN.ZD2
Checksum Recalculated: 0x0436a30c
$ python3 ../decode_effect.py -s AUTOPAN.ZD2
0x09000050 : AUTOPAN.ZD2, AutoPan (v1.40 4.10%)
$ python3 ../zoomzt2.py --include-zic -I AUTOPAN.ZD2
Installing effect: AUTOPAN.ZD2
uploading...
Uploading icon: AUTOPAN.ZIC
And... this is the result. The audio function also worked :-)
Note: I strongly recommend caution, and to disable auto-save. You don't want a bad effect to be stored in patch to automatically reload when pedal reboots....
Why not to try using the AUTOPAN.ZD2
already included on MS-50G+?
@nomadbyte Basic answer:
Longer answer:
It seems that Zoom has (deliberately?) made the ID numbers of the MS-plus overlap, which would mean that the user would have to remove another effect to allow AUTOPAN, and if our understanding of target
byte is correct this would prevent uploading anyhow.
According to the list that was uploaded, it had the MS-50G+ and MS-75CDR+ using (respectively):
0x07000010 : AUTOPAN.ZD2, AutoPan (v1.10 4.10%), 3a15ff218aa7f084f9a70113accb559a
0x07000011 : AUTOPN_C.ZD2, AutoPan (v1.00 4.10%), 949d6a486e8f5d32000f8b03a3f69001
The 'SFX' group on the MS-60B+ is moved to '0x09', '0x07' is used for 'PITCH SHIFT'
0x07000010 : B_OCTAVE.ZD2, BaOctaver (v1.10 7.46%), bf64c39ef122a091530f58f1896a126e
Yet to be understood how ID's on the MS-200D+ are allocated....
PS. I picked AutoPan to try the process, as there was a question on Reddit about how/if the Compression/Limiter effects worked in stereo, or whether then summed signals to mono first...
I'm not sure if you tried to cross-list the effects from the MS+ series vs. G5n/B3n series to see how much overlap is there. My guess is that ZOOM repackaged majority of the ZD2 effects for use on the G2 FOUR and MS+ series. Exception, of course, is the AMP/CAB and some DRV effects, which now have special handling (the Multi-layered IR and something on the MS-200D+).
My point is that there's more expectations in establishing if the new ZD2 are safely portable across the MS+ series.
All of the effects from the MS-plus and G-Series are listed (just TXT summaries, no ZD2): https://github.com/mungewell/zoom-zt2/tree/master/zoom_fx_ms-plus https://github.com/mungewell/zoom-zt2/tree/master/zoom_fx_AllZDL7
I don't have summaries for the G2 and B2... if anyone want to share.
I did some comparison with MS-50G+ to MS-75CDR+ and there's some overlap, but for some reason (memory?) the CDR has 'updated' versions. Don't know why.... perhaps Zoom is just being a dick.
If someone (with access to effects) wanted to export all the 'Code' segments, that would clarify whether it's just the wrapper (ID/Groups/etc) changing... or whether these actually are different in operation.
As stated; I think that the target
byte (at start of ZD2 file) will prevent the free copying between pedals/series. We can --force-target
but that's not particularly user friendly.
The number of parameters are often different for the "same" effect om the MS-50G+ and the MS-70CDR+, as can be seen in the effect list downloadable from the Zoom website for these two pedals. The MS-50G+ versions of the effect tends to have fewer parameters, I think. For instance, the effect SLICER.ZD2 on the MS-50G+ has 4 parameters, whereas the SLICER_C.ZD2 on the MS-70CDR+ has 5 parameters. The MS-50G+ version lacks the "Balance" parameter.
Regarding the clashing effect IDs - is there anything preventing us from just assigning a different ID to an effect? We could perhaps start using the unused bits in the middle of the 32 bit ID integer. So AUTOPAN_C.ZD2 with ID 0x07000011 on the MS-70CDR+ could be assigned the ID 0x09070011 on the MS-60B+, which would place it in the correct group on the MS-60B+, while still having a unique ID It would make exchanging patches (not effects) between pedals more difficult, though.
The presence of 'balance' param might suggest better operation in the stereo field. Maybe you have information helpful to this Reddit user... https://www.reddit.com/r/zoommultistomp/comments/1fd1b9n/true_stereo_dynamics_in_ms70cdr_plus/
We can do anything with the power of the command line ;-) I believe that the ID is not actually used within the 'Code' segment, just as a way of the pedal managing effect files and installing the right DLL when the patch is loaded.
I did think about the 'middle' bytes of the ID, perhaps someone (who is NOT this project) might use this to indicate which pedal the ZD2 effect came from (ie byte is good to encode 50, 60, 70 or 200)... their tool could even be smart to zero this out when 'uploading' with the native pedal.
If someone (with access to effects) wanted to export all the 'Code' segments, that would clarify whether it's just the wrapper (ID/Groups/etc) changing... or whether these actually are different in operation.
Here you go:
python .\decode_effect.py .\Everything-ms50gp\AUTOPAN.ZD2 -c autopan.code
python .\decode_effect.py .\Everything-ms70cdrp\AUTOPN_C.ZD2 -c autopn_c.code
du -b *.code
12655 autopan.code
13183 autopn_c.code
So the code segments differ in size. The MS-70CDR+ one is larger.
I converted the code segments to hex strings and did a diff on the resulting files cat autopan.code | hexdump -v -e '/1 "%02x\n"' > autopan.hex
. Some similarities and some differences. Large chunks of similarities, though.
I then tried comparing the AUTOPAN.ZD2 (from MS-50G+) code hexdump to a hexdump of the code segment of 160_COMP.ZD2 (from MS-70CDR+). There were less similarities there. I'm not sure if there's anything interesting to be read from this analysis, aside from the fact that the two files differ in size and contents. Someone who understands Texas Instrument assembly might be able to say something more sensible about it by looking at the disassembled code for each.
There are some Linux cross compilers and a 'free' Windows one from TI, but to be honest this is above my level of competence.
The decode_bdl.py
script has the ability to list the symbol names, and shows how to pull data out of an elf...
There's the RainSel/RTFM stuff which was done on OG MS pedals, perhaps would be useful if anyone wanted to dig deeper. A Reddit user did a demo video, and comments have links to details. https://www.reddit.com/r/zoommultistomp/comments/1cz2k0t/i_recorded_a_tutorial_on_how_to_use_div0_and_rtfm/
Is there a compassionate soul out there willing to share the MS60B+'s Clear DRV (LINPRE.ZD2) with me? I don't have an MS+ around to extract it. I'm more than ready to try it in my B1Xfour.
The immediate answer is NO, it looks like Zoom have jeri-rigged the ID and Groups to be different between the series
The symbols listed in the ELF Code segment are very similar, and there are relatively small difference in the hexdump of the Code
These symbol name differences might just be as the ZD2 has been re-compiled. Looking at a 2nd effect (ZNR) it has completely different number symbols too...