search

mungewell / zoom-zt2

Python script to install/remove effects from the Zoom G1Four pedal
MIT License
50 stars 10 forks source link

Can't load certain effects - Holdverb, Particleverb, but even native TapeEcho3 to G1x Four #39

Open Roseweave opened 2 years ago

Roseweave commented 2 years ago

I'm really stumped as to why effects sometimes load on this box and sometimes they don't. I was successfully able to load the Ampeg model on, which is great for making Stoner/Doom sounds.

I removed the regular tape echo to replace it with the Watkins/Tape Echo 3, since I'm a bit of a Bauhaus fan. No dice. After several attempts I eventually got Zoom Guitar Lab to add it.

So why would zt2 struggle with loading a regular effect?

I'm thinking of trying to older custom firmware loader but don't want to reset all the custom selections i've made for amps and effects and have no idea if that will work either.

Why doesn't it work? I can't think of any reasonable reason it wouldn't. It's one thing if it crashes the G1x Four, but it doesn't even try. So many of the best effects I was looking forward to just aren't available and I don't understand why.

Roseweave commented 2 years ago

I should also note that the G3n had a Hold Delay, and i can't get that to work either. the ripped version might be odd though, as there is a Hold Verb and I'm not sure whether that was ever added to the G3/5n

mungewell commented 2 years ago

The first question would be whether the effects are exactly the same for each pedal. From what I have downloaded that appears to be true, but not certain...

$ find . -name 'HOLDDLY.ZD2' -exec md5sum {} \;
7d7792f52df0cdc873c48b2923a69b6b  ./G11/unzipped/HOLDDLY.ZD2
7d7792f52df0cdc873c48b2923a69b6b  ./G3n/HOLDDLY.ZD2

It's highly possible that my code has a bug which is triggered by a particular ZD2. When sending to the pedal, the data is encoded and then also checked with a CRC32. I could have got either of these things wrong...

I upload some new capabilities to 'peer' into the ZD2 files

$ python3 decode_effect.py --help
usage: decode_effect [-h] [-d] [-s] [-b BITMAP] [-i INFO] [-c CODE] [-j]
                     [-x XML] [-t TEXT] [-D DONOR] [-B] [-T] [-I] [-C] [-X]
                     [-o OUTPUT]
                     FILE

positional arguments:
  FILE                  File to process

optional arguments:
  -h, --help            show this help message and exit
  -d, --dump            dump configuration to text
  -s, --summary         summarized configuration in human readable form
  -b BITMAP, --bitmap BITMAP
                        extract Icon/Bitmap to FILE
  -i INFO, --info INFO  extract Info to FILE
  -c CODE, --code CODE  extract Code to FILE

Language:
  Extract either English or Japanese segments

  -j, --japan           select Japanese version for export
  -x XML, --xml XML     extract XML to FILE
  -t TEXT, --text TEXT  extract Text to FILE

Donor:
  Take replacement sections from a donor ZD2

  -D DONOR, --donor DONOR
                        specify donor ZD2 FILE
  -B, --donor-bitmap    extract Icon/Bitmap from donor
  -T, --donor-text      extract Text from donor
  -I, --donor-info      extract Info from donor
  -C, --donor-code      extract Code from donor
  -X, --donor-xml       extract XML from donor
  -o OUTPUT, --output OUTPUT
                        output combined result to FILE
Roseweave commented 2 years ago

The first question would be whether the effects are exactly the same for each pedal. From what I have downloaded that appears to be true, but not certain...

$ find . -name 'HOLDDLY.ZD2' -exec md5sum {} \;
7d7792f52df0cdc873c48b2923a69b6b  ./G11/unzipped/HOLDDLY.ZD2
7d7792f52df0cdc873c48b2923a69b6b  ./G3n/HOLDDLY.ZD2

It's highly possible that my code has a bug which is triggered by a particular ZD2. When sending to the pedal, the data is encoded and then also checked with a CRC32. I could have got either of these things wrong...

I upload some new capabilities to 'peer' into the ZD2 files

$ python3 decode_effect.py --help
usage: decode_effect [-h] [-d] [-s] [-b BITMAP] [-i INFO] [-c CODE] [-j]
                     [-x XML] [-t TEXT] [-D DONOR] [-B] [-T] [-I] [-C] [-X]
                     [-o OUTPUT]
                     FILE

positional arguments:
  FILE                  File to process

optional arguments:
  -h, --help            show this help message and exit
  -d, --dump            dump configuration to text
  -s, --summary         summarized configuration in human readable form
  -b BITMAP, --bitmap BITMAP
                        extract Icon/Bitmap to FILE
  -i INFO, --info INFO  extract Info to FILE
  -c CODE, --code CODE  extract Code to FILE

Language:
  Extract either English or Japanese segments

  -j, --japan           select Japanese version for export
  -x XML, --xml XML     extract XML to FILE
  -t TEXT, --text TEXT  extract Text to FILE

Donor:
  Take replacement sections from a donor ZD2

  -D DONOR, --donor DONOR
                        specify donor ZD2 FILE
  -B, --donor-bitmap    extract Icon/Bitmap from donor
  -T, --donor-text      extract Text from donor
  -I, --donor-info      extract Info from donor
  -C, --donor-code      extract Code from donor
  -X, --donor-xml       extract XML from donor
  -o OUTPUT, --output OUTPUT
                        output combined result to FILE

Hmm. Do you have a copy of the G3n ZD2s to compare? if so I wouldn't mind having them and trying them out myself. I'd be really interested in learning more about how zd2s work in general too - my own programming skills have atrophied over the last decade and a half, but I'd be very interested in what could be done, it feels like it should be theoretically possible to figure out how to tweak the 2 page interfaces to one page for example, even if it means losing an option.

Might be worth checking the different copies of the Copycat delay as an example too.

Do you have any suggestions for how to use this donor ability? Could you rob the code from Holdverb and attack it to something else so it works? Very impressive work either way.

(also - I wonder if it's possible to optimise space usage on the 1 Four series? They have very little space. Short of swapping out for a different chip, I wonder if it's possible for example to swap out the drum samples for smaller file sizes but same or better quality, they're pretty bad as is, maybe replacing them with something like TR909 samples would be better in the long run? Or if certain effects can be recompiled to be smaller? They're already so tiny for how good the modelling is, very curious how that works - is there a lot of internal code/libraries being referred back to? I would really love if there was a way to put in a bigger chip just to load everything on though...)

mungewell commented 2 years ago

Ran a quick test on my G1XFour and attempted to install HOLDDLY.ZD2, which failed for some reason - but without any errors...

$ python3 zoomzt2.py -R FLST_SEQ.ZT2 -s
Group 7 : SFX
    BOMBER.ZD2 (ver= 1.30 ), group= 7 , id= 0x7000010 , installed= 1
$ python3 zoomzt2.py -I  PARAEQ.ZD2 
Installing effect: PARAEQ.ZD2
$ python3 zoomzt2.py -R FLST_SEQ.ZT2 -s
Group 7 : SFX
    BOMBER.ZD2 (ver= 1.30 ), group= 7 , id= 0x7000010 , installed= 1
Group 2 : FILTER
    PARAEQ.ZD2 (ver= 1.20 ), group= 2 , id= 0x2000070 , installed= 1

$ md5sum HOLDDLY.ZD2 
7d7792f52df0cdc873c48b2923a69b6b  HOLDDLY.ZD2
$ python3 zoomzt2.py -I HOLDDLY.ZD2
Installing effect: HOLDDLY.ZD2
$ python3 zoomzt2.py -R FLST_SEQ.ZT2 -s
Group 2 : FILTER
    PARAEQ.ZD2 (ver= 1.20 ), group= 2 , id= 0x2000070 , installed= 1
Group 7 : SFX
    BOMBER.ZD2 (ver= 1.30 ), group= 7 , id= 0x7000010 , installed= 1

New effect is NOT added into the FLST_SEQ... and is not listed under the files tab of the GUI.

It turns out that it is actively blocked by GUARDZDL.ZT2.

$ strings GUARDZDL.ZT2 | grep HOLD
HOLDDLY.ZD2
HOLDVERB.ZD2
mungewell commented 2 years ago

On TAPEECHO... it appears that there are two versions.

$ find -iname 'tape*'
./B1X FOUR/TAPEECHO.zip
./G1 FOUR/TAPEECHO.zip
./B1 FOUR/TAPEECHO.zip
./G3n/TAPEECHO.zip
./G3n/TAPEECH3.zip

With the 3 version being (likewise) actively blocked.

$ strings GUARDZDL.ZT2 | grep TAPE
TAPEECH3.ZD2
mungewell commented 2 years ago

I don't know the full reason(s) that Zoom does the blocking (with GUARDZDL.ZT2), the most likely is that some effects display GUI across multiple screens - which the G1Four (and friends) do not have.

GuitarLab pulls the effect files from a web page, you can use this utility. https://github.com/fuzboxz/zdownload

Your understanding of the donor feature is correct, it will pull blocks from one ZD2 and inject into another. I think that the pedal only really cares about the code block, and the others are really just meta data for GuitarLab to know what the effect is.

mungewell commented 2 years ago

Drum samples are just raw audio data, if you wanted to save a little space you replace them with very small files. I don't know whether it would cause problems if they were totally absent.

BTW the drum patterns are hard coded into the FW, long discussion here: https://github.com/Barsik-Barbosik/Zoom-Firmware-Editor/issues/17

We could make custom FW with a different pattern, but I don't think that anyone is that interested in following through on that...

Roseweave commented 2 years ago

On TAPEECHO... it appears that there are two versions.

$ find -iname 'tape*'
./B1X FOUR/TAPEECHO.zip
./G1 FOUR/TAPEECHO.zip
./B1 FOUR/TAPEECHO.zip
./G3n/TAPEECHO.zip
./G3n/TAPEECH3.zip

With the 3 version being (likewise) actively blocked.

$ strings GUARDZDL.ZT2 | grep TAPE
TAPEECH3.ZD2

I was able to install it with the Zoom Guitar Lab utility though - it's listed as a G1xFour effect and was playing around with it last night. Very odd?

Roseweave commented 2 years ago

I don't know the full reason(s) that Zoom does the blocking (with GUARDZDL.ZT2), the most likely is that some effects display GUI across multiple screens - which the G1Four (and friends) do not have.

GuitarLab pulls the effect files from a web page, you can use this utility. https://github.com/fuzboxz/zdownload

Your understanding of the donor feature is correct, it will pull blocks from one ZD2 and inject into another. I think that the pedal only really cares about the code block, and the others are really just meta data for GuitarLab to know what the effect is.

Doesn't the G3n only use one screen per effect though? Shouldn't any effect from that theoretically be compatible?

Also, what happens if you upload a custom GUARDZDL.ZT2? Would it crash if I tried to load the G3n Hold Delay on that?

I would be interested in figuring out how to decompile these effects and changing the interface, it could be a real game changer. I think I saw someone post about the DSP chip earlier, do you have any resources on that?

mungewell commented 1 year ago

Pulling the effects from GL7, it seems that there are now more variations of 'TapeEcho'.

zoom_fx_AllZDL7$ grep TapeEcho master.txt 
0x08000030 : TapeEcho (v1.50, 6.97%), 0xd9a91384acf6be71deac3ddddf58e0fb
0x08000031 : TapeEcho (v1.00, 6.97%), 0xc7b964a98bf79631f5809f6d9f69085f
0x080000f0 : TapeEcho3 (v1.30, 17.55%), 0x797740a6d8b0a9c0aaae776efc45c88e
0x080000f1 : TapeEcho3 (v1.20, 17.88%), 0x1f45a010525bf52b7195bf4c35b89164
0x09090030 : TapeEcho (v1.00, 8.20%), 0xaa5422125327fc2869f0ba28ccee40b3

They are used on the following pedals:

zoom_fx_AllZDL7$ grep TapeEcho master.txt | cut -d ',' -f 3 > hitlist.txt
zoom_fx_AllZDL7$ find . -name 'list_sorted.txt' -exec grep -f hitlist.txt {} \;
0x08000030 : TapeEcho (v1.50, 6.97%), 0xd9a91384acf6be71deac3ddddf58e0fb, ./A1 FOUR/unzipped/TAPEECHO.ZD2
0x080000f1 : TapeEcho3 (v1.20, 17.88%), 0x1f45a010525bf52b7195bf4c35b89164, ./A1 FOUR/unzipped/TPEC3_3S.ZD2
0x08000030 : TapeEcho (v1.50, 6.97%), 0xd9a91384acf6be71deac3ddddf58e0fb, ./A1X FOUR/unzipped/TAPEECHO.ZD2
0x080000f1 : TapeEcho3 (v1.20, 17.88%), 0x1f45a010525bf52b7195bf4c35b89164, ./A1X FOUR/unzipped/TPEC3_3S.ZD2
0x08000030 : TapeEcho (v1.50, 6.97%), 0xd9a91384acf6be71deac3ddddf58e0fb, ./G1X FOUR/unzipped/TAPEECHO.ZD2
0x080000f1 : TapeEcho3 (v1.20, 17.88%), 0x1f45a010525bf52b7195bf4c35b89164, ./G1X FOUR/unzipped/TPEC3_3S.ZD2
0x08000030 : TapeEcho (v1.50, 6.97%), 0xd9a91384acf6be71deac3ddddf58e0fb, ./G11/unzipped/TAPEECHO.ZD2
0x080000f0 : TapeEcho3 (v1.30, 17.55%), 0x797740a6d8b0a9c0aaae776efc45c88e, ./G11/unzipped/TAPEECH3.ZD2
0x08000030 : TapeEcho (v1.50, 6.97%), 0xd9a91384acf6be71deac3ddddf58e0fb, ./B1X FOUR/unzipped/TAPEECHO.ZD2
0x08000030 : TapeEcho (v1.50, 6.97%), 0xd9a91384acf6be71deac3ddddf58e0fb, ./G1 FOUR/unzipped/TAPEECHO.ZD2
0x080000f1 : TapeEcho3 (v1.20, 17.88%), 0x1f45a010525bf52b7195bf4c35b89164, ./G1 FOUR/unzipped/TPEC3_3S.ZD2
0x08000030 : TapeEcho (v1.50, 6.97%), 0xd9a91384acf6be71deac3ddddf58e0fb, ./B1 FOUR/unzipped/TAPEECHO.ZD2
0x08000030 : TapeEcho (v1.50, 6.97%), 0xd9a91384acf6be71deac3ddddf58e0fb, ./G3n/unzipped/TAPEECHO.ZD2
0x080000f0 : TapeEcho3 (v1.30, 17.55%), 0x797740a6d8b0a9c0aaae776efc45c88e, ./G3n/unzipped/TAPEECH3.ZD2
0x08000031 : TapeEcho (v1.00, 6.97%), 0xc7b964a98bf79631f5809f6d9f69085f, ./R20/unzipped/TPECHBAL.ZD2
0x080000f1 : TapeEcho3 (v1.20, 17.88%), 0x1f45a010525bf52b7195bf4c35b89164, ./R20/unzipped/TPEC3_3S.ZD2
0x08000030 : TapeEcho (v1.50, 6.97%), 0xd9a91384acf6be71deac3ddddf58e0fb, ./B3n/unzipped/TAPEECHO.ZD2
0x08000030 : TapeEcho (v1.50, 6.97%), 0xd9a91384acf6be71deac3ddddf58e0fb, ./G6/unzipped/TAPEECHO.ZD2
0x080000f1 : TapeEcho3 (v1.20, 17.88%), 0x1f45a010525bf52b7195bf4c35b89164, ./G6/unzipped/TPEC3_3S.ZD2
0x09090030 : TapeEcho (v1.00, 8.20%), 0xaa5422125327fc2869f0ba28ccee40b3, ./B6/unzipped/TPECHO88.ZD2
0x08000030 : TapeEcho (v1.50, 6.97%), 0xd9a91384acf6be71deac3ddddf58e0fb, ./G5n/unzipped/TAPEECHO.ZD2
0x080000f0 : TapeEcho3 (v1.30, 17.55%), 0x797740a6d8b0a9c0aaae776efc45c88e, ./G5n/unzipped/TAPEECH3.ZD2
0x08000031 : TapeEcho (v1.00, 6.97%), 0xc7b964a98bf79631f5809f6d9f69085f, ./H8/unzipped/TPECHBAL.ZD2
0x080000f1 : TapeEcho3 (v1.20, 17.88%), 0x1f45a010525bf52b7195bf4c35b89164, ./H8/unzipped/TPEC3_3S.ZD2
0x08000030 : TapeEcho (v1.50, 6.97%), 0xd9a91384acf6be71deac3ddddf58e0fb, ./G3Xn/unzipped/TAPEECHO.ZD2
0x080000f0 : TapeEcho3 (v1.30, 17.55%), 0x797740a6d8b0a9c0aaae776efc45c88e, ./G3Xn/unzipped/TAPEECH3.ZD2
nomadbyte commented 1 year ago

Regarding the nomenclature {effect-name-tag}{suffix}.ZD2:

suffix meaning details
1U single unit (screen) on one-screen units the wide-effects, which have 8 parameters (controlled by 4 knobs), need to be paged over 3pages: (3params + Dummy), (3params+Dummy), (2params + Dummy); the Dummy parameters are used for paging. These additional parameters could be seen in the ELF. Additionally, the on-device icon (ELF-embedded) is recoded from 2U into 1U size to fit ~23x32px allotted (ref: [#52]). Example: MATCH_30.ZD2 vs MACH301U.ZD2.
3S 3000ms (delay) the big-boy units in G Series are able to process 4000ms delays/reverb effects but the G1/B1/A1 FOUR units are able to handle only up to 3000ms (3sec). This is likely due to memory or processing power limits. Asking these units to produce over 3sec delay results in kinda noisy whoosh.

For these reasons, Zoom engineers created the respective 1U, 3S versions of most but not all corresponding modules and put the respective names of the "unrestricted" modules into GUARDZDL.ZT2 to avoid possible problems if anyone tried to load such modules on the restricted hardware. That's my understanding of this.

mungewell commented 1 year ago

I'd have to question whether we could patch the effect parameter table (in ELF) to make effects work OK? Or would we need to look deeper in the .text to find where space/memory is alloc'ed for the maximum allowable 'time'.

$ strings GUARDZDL.ZT2 | grep ICE              
ICE_DLY.ZD2

G1Four - ICEDLY3S.ZD2

00000540  00 00 00 00 00 00 00 00  49 43 45 20 44 65 6c 61  |........ICE Dela|
00000550  79 00 00 00 ff ff ff ff  00 00 00 00 01 00 00 00  |y...............|
00000560  00 00 00 00 f4 1e 00 00  00 00 00 00 00 00 00 00  |................|
00000570  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000580  49 4e 54 56 4c 00 00 00  00 00 00 00 1e 00 00 00  |INTVL...........|
00000590  1c 00 00 00 00 00 00 00  00 00 00 00 74 17 00 00  |............t...|
000005a0  00 00 00 00 60 22 00 00  00 00 00 00 00 00 00 00  |....`"..........|
000005b0  00 00 00 00 00 00 00 00  54 69 6d 65 00 00 00 00  |........Time....|
000005c0  00 00 00 00 a3 03 00 00  a0 03 00 00 00 00 00 00  |................|
                      ^^ ^^ 0x03a3 = 931ms

G11 - ICE_DLY.ZD2

00000540  00 00 00 00 00 00 00 00  49 43 45 20 44 65 6c 61  |........ICE Dela|
00000550  79 00 00 00 ff ff ff ff  00 00 00 00 01 00 00 00  |y...............|
00000560  00 00 00 00 f8 1e 00 00  00 00 00 00 00 00 00 00  |................|
00000570  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000580  49 4e 54 56 4c 00 00 00  00 00 00 00 1e 00 00 00  |INTVL...........|
00000590  1c 00 00 00 00 00 00 00  00 00 00 00 78 17 00 00  |............x...|
000005a0  00 00 00 00 60 22 00 00  00 00 00 00 00 00 00 00  |....`"..........|
000005b0  00 00 00 00 00 00 00 00  54 69 6d 65 00 00 00 00  |........Time....|
000005c0  00 00 00 00 e7 04 00 00  e0 04 00 00 00 00 00 00  |................|
                      ^^ ^^ 0x04e7 = 1255ms

Regardless, I think that having two versions of (essentially) the same effect helps us understand the meaning of various bits of the ELF. Screenshot_2023-01-08_15-10-11

nomadbyte commented 1 year ago

Or would we need to look deeper in the .text to find where space/memory is alloc'ed for the maximum allowable 'time'.

Reaching the stage of the diminishing returns here... We already have the 3S versions which are OK. I'm not sure if 4sec delay is such a must vs. 3sec.

Also, I believe the limitation is on the hardware level, simply a smaller RAM buffer on the die somewhere, otherwise it's just too much effort for Zoom engineers to go to these lengths for simple product segmentation. Did anyone even notice that the delay tops at 3sec??

What you showed above are likely the default parameter settings, as it's part of the "OnOff" section. In case of the max 3S Time value, it appears to be 3018 (from 0) (not sure how it's encoded in OnOff). The G1 FOUR device lets adjust the delay Time with the knob from 1 up till 3000, then by note duration: 19 values).

Perhaps, someone could explain in simple terms the OnOff extraction and mmax manipulations specifically done in @shooking script:

https://github.com/shooking/ZoomPedalFun/blob/ec6031323511d7116f1d870304fad0b0db318bbd/python/zoomzt2_shooking.py#L818-L833

P.S. Looking in the ICEDLY3S.ZD2 ELF, there's the reference to ZDL_DLY_IceDelay_ShortExRam.out, I guess that's the reason...

shooking commented 1 year ago

Regarding the ELF ...Ti compiler chain is free. See https://github.com/shooking/ZoomPedalFun/issues/18

I am pretty sure I explained on some YouTube how I reversed the FX for mmax on ZDL and ZD2 - I will try to find and post here. But in a nutshell I looked at the binary in HxD then found a pattern. Normally I find 26 bytes is a good window to explore. So I search for OnOff and relative to there the parameters can be found. There are some lookup tables that I haven't figured out. For time values or Hz. The ASCII screen dump is useful here but currently I am Happy to know max range of a param, default and not as bothered to display in human terms ... midi works for me.

nomadbyte commented 1 year ago

Regarding OnOff values encoding, what I find peculiar is the use of base 256. For example,

[ca 0b] = 0xca + 0x0b*256 = 3018 = 0x0bca
[e7 04] = 0xe7+ 0x04*256 = 1255 = 0x04e7

I guess, the idea is to scale the target value by 256, then add the remainder encoded into a byte.

Perhaps, such scaling is due to encoders having 256 positions? But in these models the knob encoders are limitless, so they click as many times as needed. In the examples above, each click advances the value by 1 point.

Anyone has better clarity on such encoding approach?

P.S. Ok, it's just a usual unsigned integer, little-endian :)

shooking commented 1 year ago

I view it this way. The firmware is in hex so 256 is natural base to use. Zoom encodes a max. If it is larger than 255 they have to use another byte.

I must be misunderstanding your question.

nomadbyte commented 1 year ago

Never mind. It's just the normal unsigned integer (little-endian). I got thrown off by the explicit use of 256 in your code. Thanks.

mungewell commented 1 year ago

Just to confirm what @shooking said about the midi values being the 'raw' non-table/non-offset values. Setting a value of '1' appears as '61' on screen for Ice-Delay Time parameter

Note: whilst sending raw values directly via midi they are 7-bit, so you need to do a bit of math.

$ 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: ICE Delay (On)
INTVL : OCT
Time : 60
F.B : 46
Mix : 36
---

$ amidi -p hw:2,0,0 -S 'F0 52 00 6e 50 F7'
$ amidi -p hw:2,0,0 -S 'f0 52 00 6e 64 03 00 00 03 01 00 00 00 00 f7'
                                                   ^^ ^^ ^^ ^^ 7bit value = 0x0001
                                                ^^ parm3 = 2nd dial
                                             ^^ slot 0

$ 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: ICE Delay (On)
INTVL : OCT
Time : 61
F.B : 46
Mix : 36
---
mungewell commented 1 year ago

@nomadbyte I previously took some pictures of the G1Four PCB. There is a 'TMS320 C6745DPTP3' CPU and a 2nd chip (IC2) from EtronTech - but not clear enough to read part number. Will confirm next weekend.

shooking commented 1 year ago

For what it's worth I made a video https://youtu.be/1Y7njsB-mNc

10:46 you can see the processors that @mungewell mentioned.

That's where I got the idea of downloading the Ti compiler and then found how to extract the ELF and feed it into it.

I am in the final stages of hardware remote control via a DB25. Just got to piece the code together and determine where to drill holes in my case. It will be a bit like a G5n (which I mainly use).

shooking commented 1 year ago

![Uploading Screenshot_20230109-194048_YouTube.jpg…]() Hope this helps.

em638165t

Not sure if the photo is loading async or just failed from my phone

nomadbyte commented 1 year ago

... Setting a value of '1' appears as '61' on screen for Ice-Delay Time parameter

The parameter values sent with Sysex:<64 03> are set relative to the defined minimum value of the parameter.

I looked at the SoftEcho effect, it also has the Time parameter on knob2 defined in decimal range [19, 581]. So that parameter's minimum value is mapped onto 0, parameter's maximum value corresponds to (581-19)=562.

For example, to set this parameter to 123 value, one needs to send (123-19)=104=0x68 (encoded in base-128) in the Sysex:<64 03> message for the knob:

amidi -p hw:1,0,0 -S "F0 52 00 6E 64 03 00 00 03 68 00 00 00 00 F7" -t1 -d
mungewell commented 1 year ago

Looks like everything aligns. Great job everyone!

@nomadbyte where are you gettting the [19, 581] range from? Other than looking at the real pedal, or Zoom's documentation??

[deleted my previous comment - got confused and went the wrong way in my hex conversion...]

19 = 0x13

nomadbyte commented 1 year ago

... where are you getting the [19, 581] range from?

This is what's shown on the device screen. The "OnOff" section shows the mapped max value 562=0x0232

mungewell commented 1 year ago

I get that the 'raw' max value 562=0x0232, but how do we know that the offset of 19 should be applied?

shooking commented 1 year ago

@nomadbyte - just checking if you know about the decodes I did on my site? https://github.com/shooking/ZoomPedalFun/blob/main/GCE-3/DerivedData/1.20/G5n_3.00/ICE_DLY.ZD2.json

So not sure if this is the same ice delay that @mungewell describes above. Let's check Hmmh I see G1Four - ICEDLY3S.ZD2

OK so that's this one https://github.com/shooking/ZoomPedalFun/blob/main/GCE-3/DerivedData/1.20/G1FOUR_1.10/ICEDLY3S.ZD2.json

I dont see any [581, 19]? My guess is it is related to your earlier comment:

What you showed above are likely the default parameter settings, as it's part of the "OnOff" section. In case of the max 3S Time value, it appears to be 3018 (from 0) (not sure how it's encoded in OnOff). The G1 FOUR device lets adjust the delay Time with the knob from 1 up till 3000, then by note duration: 19 values).`

I am seeing on G1Four

            {
                  "name": "Time",
                  "explanation": "Sets the delay time.",
                  "blackback": false,
                  "pedal": false,
                  "mmax": 931,
                  "mdefault": 928
            },

And on G5n

            {
                  "name": "Time",
                  "explanation": "Sets the delay time.",
                  "blackback": false,
                  "pedal": false,
                  "mmax": 1255,
                  "mdefault": 1248
            },

Let me just check tape echo, another on reported above - simply because I have a B1XFour infront of me right now (I gave my G1XFour to a youth at the church so he can learn guitar).

https://github.com/shooking/ZoomPedalFun/blob/main/GCE-3/DerivedData/1.20/G1FOUR_1.10/TAPEECHO.ZD2.json cf https://github.com/shooking/ZoomPedalFun/blob/main/GCE-3/DerivedData/1.20/G5n_3.00/TAPEECHO.ZD2.json


{
      "FX": {
            "name": "TapeEcho",
            "description": "This effect simulates a tape echo. Changing the \"Time\" parameter changes the pitch of the echoes.",
            "version": "1.50",
            "fxid": 48,
            "gid": 64,
            "group": 8,
            "numParams": 4,
            "numSlots": 1,
            "filename": "TAPEECHO.ZD2.BMP"
      },
      "Parameters": [
            {
                  "name": "Time",
                  "explanation": "Sets the delay time.",
                  "blackback": false,
                  "pedal": false,
                  "mmax": 2014,
                  "mdefault": 559
            },

v

{
      "FX": {
            "name": "TapeEcho",
            "description": "This effect simulates a tape echo. Changing the \"Time\" parameter changes the pitch of the echoes.",
            "version": "1.50",
            "fxid": 48,
            "gid": 64,
            "group": 8,
            "numParams": 4,
            "numSlots": 1,
            "filename": "TAPEECHO.ZD2.BMP"
      },
      "Parameters": [
            {
                  "name": "Time",
                  "explanation": "Sets the delay time.",
                  "blackback": false,
                  "pedal": false,
                  "mmax": 2014,
                  "mdefault": 559
            },

So the come out identical - I guess on on the "guard" list. So according to my code the time has 2015 steps (0 - 2014) and 559 as a default. Checking on the screen now

0 midi = 1 (ms) displayed 1 midi = 2 (ms) ... 1999 = 2000 (ms) 1 semi quaver 2 crotchet 3 3 dotted semi quaver 4 quaver 5 semi brieve 3 6 dotted quaver 7 crotchet 8 dotted crotchet 9 crotchet x 2 10 crotchet x 3 11 crotchet x 4 12 crotchet x 5 13 crotchet x 6 14 crotchet x 7 15 crotchet x 8 15 symbols => (1999 - 0) + 1 + (15 - 1 + 1) = 2015

QED?

Please check your max/min against the JSON decodes - let me know if I have made a mistake. Best regards Steve

shooking commented 1 year ago

I completely forgot! I do have a G5n and G1XFour still - the GCE-3!

G5n_ice_delay_0 G5n_ice_delay_max

so we can see the ICE Delay on a emulated G5n (I cant be bothered to got to the garage to get the real box) is 60 at rest and moves to the crotchet x 8 as max which is 2014 midi.

So in summary - please check your min/max extractions against my JSON. I am pretty sure they are correct - I even did this for the G5 and the older pedals from ZDL. Now, that presents a different set of challenges, but the same idea works - only the offsets change to protect the innocent.

Mungewell and I collaborated on the ASCII screens - it is essentially how we 1st virtually met. I never bothered to use it though because I am ok working in Midi space. End users would "demand" correct translation - let them do it!

Out of interest @mungewell - what does the ASCII decode when one gets to these funny characters? I was thinking it must be a lookup into one of the tables (scale, time etc) Zoom documents - I couldnt get my terminal to display the Unicode properly for a while so I gave up.

nomadbyte commented 1 year ago

...I dont see any [581, 19]?

@shooking ,this Time parameter range (rather [19, 581]) is for SoftEcho (3S variant), not for IceDelay. You should be able to load it on your emulated G1X FOUR.

shooking commented 1 year ago

What pedal is it originally for? Where can we get this file? I can find it in my GCE-3 Derived data "SOFTEC3S.ZD2" and it appears to be there for a load of pedals?

https://github.com/shooking/ZoomPedalFun/blob/main/GCE-3/DerivedData/1.20/G5n_3.00/SOFTECHO.ZD2.json

            {
                  "name": "Time",
                  "explanation": "Sets the delay time.",
                  "blackback": false,
                  "pedal": false,
                  "mmax": 562,
                  "mdefault": 387
            },

or this G1XFour specific version? https://github.com/shooking/ZoomPedalFun/blob/main/GCE-3/DerivedData/1.20/G1XFOUR/SOFTEC3S.ZD2.json

            {
                  "name": "Time",
                  "explanation": "Sets the delay time.",
                  "blackback": false,
                  "pedal": false,
                  "mmax": 562,
                  "mdefault": 387
            },

looks the same.

As you said, the 3S you believe means 3 second delay? Except it seems to be 2 seconds for the ones I checked? But I see that the 3S is specifically for the B1XFour series and the non-3S is for the older pedals?

ZoomPedalFun\G3n\DerivedData\2.20\SOFTECHO.ZD2
ZoomPedalFun\GCE-3\DerivedData\1.20\A1FOUR_1.10\SOFTEC3S.ZD2
ZoomPedalFun\GCE-3\DerivedData\1.20\A1XFOUR_1.10\SOFTEC3S.ZD2
ZoomPedalFun\GCE-3\DerivedData\1.20\G1FOUR_1.10\SOFTEC3S.ZD2
ZoomPedalFun\GCE-3\DerivedData\1.20\G1XFOUR\SOFTEC3S.ZD2
ZoomPedalFun\GCE-3\DerivedData\1.20\G3n_2.00\SOFTECHO.ZD2
ZoomPedalFun\GCE-3\DerivedData\1.20\G3Xn_2.20\SOFTECHO.ZD2
ZoomPedalFun\GCE-3\DerivedData\1.20\G5n_3.00\SOFTECHO.ZD2

Maybe you can share the specific ZD2, a link to it or check out if I have the same file in ZoomPedalFun - which if so would be one I looked at above and they look pretty similar from a parameters perspective. Sure the ID changes slightly.

shooking commented 1 year ago

ah ok ... so when I add SoftEcho into the G5n (GCE-3) we see it is same as the G1XFour. But look at the ASCII values - recall I only work in Midi values. I think we are dangerously close to agreeing here - just what measurement space!

G1XFour_min_def_max

nomadbyte commented 1 year ago

As you probably realized, the module is SOFTEC3S.ZD2, it's loaded into several compatible models, including G1/G1X FOUR.

All of those models appear to have the hardware able to handle only up to 3sec of buffered data needed for processing the delay/reverb effects, unlike higher-end models which can do up to 4sec.

shooking commented 1 year ago

I am more than a little confused here though.

The assertion is 3s => 3s max delay. Maybe the originals overwrote the stack, crashed the pedals, Zoom discovered this and released new ZD2? Whatever - when we agree on a filename and examine it then in this case there is no discernible difference between the 3S and non-3S version of SOFT Echo.

The difference is you are describing the max / min in User space. I am describing in Midi space.

The benefit of what I am doing - we have a min (always 0) and max midi value. No matter - if you send more then the Zoom truncates to the max. But given Zoom have taken the trouble to allow us to find max/min I use the midi - my embedded processor will be talking midi or sending pulses to the hardware.

Users of course like the "60ms", or in this case "19ms". But how to derive the crotchet symbols? I think the ASCII representation send a lookup value for an index - but can we tell the difference between 1 and 1 - I guess the ASCII would send 19 and then 1 ... so if you get an ASCII "lower" than the 0th setting then it must be an index.

Anyhow, it seems to me the 3S/non are the same in this case - at least when viewed on their respective pedals. Nothing to see here?

Now - I suspect the G1X cant handle the processing power for particle reverb - hence why I bought a B1On then started to get really into these pedals.

nomadbyte commented 1 year ago

...I get that the 'raw' max value 562=0x0232, but how do we know that the offset of 19 should be applied?

@mungewell : Well, the actual data ??string for the minimum value offset looks like being processed by some dedicated function (GetString_offset_19(?) in case of SOFTEC3S.ZD2, GetString_OFFSET_980_Sync(?) for ICEDLY3S.ZD2 etc.)

$ readelf -a -W SOFTEC3S.ZD2.elf |grep "GetString_"
...
    43: 00001280     0 FUNC    LOCAL  HIDDEN     4 GetString_offset_19

The function may be doing a lookup in some LUT or has the value hard-coded, not sure. Obviously some of the limit values are being hard-coded in the function names.

Roseweave commented 1 year ago

any progress on this since? catching up through the thread but a bit lost