Max FX for a Pedal? - Githubissues

shooking commented 2 years ago

Wondering if it is this sysex?

SEND: f052006e48f7 RECV: f052006e4701000000000100000000000000000009f7

G5n returns 9 as above (last int) G3n returns 7 B1XFour returns 7 - my guess is 5 plus rhythm + looper = 7?

Any thoughts appreciated.

shooking commented 2 years ago

So I created a "7fx" on a B1XFour. 5 FX are displayed but it uses 7 slots

nomadbyte commented 1 year ago

So I created a "7fx" on a B1XFour. 5 FX are displayed but it uses 7 slots

Not sure if you had to tweak MIDI to get those 7 screens for B1X FOUR in the GL.

Looks like the patch above uses 2 "wide" effects (those that take multiple pages). So even though there are 5 effect modules in the chain, they occupy the 7 screens. This can also be done directly on the pedal itself (at least on G1 FOUR).

In fact it's possible to load "wide" effects into all of the allotted 5 positions in the chain (thus with 5*2=10 total page count). However, in practice this would be restricted by the available DSP Load.

ToneLib-Zoom-G1FOUR-patch-with-5-wide-effects

P.S. Curiously, it looks like ToneLib Zoom (v4.3.1) has a bug that disallows adding an effect module into remaining free position when the current "page-count" exceeds the allotted number of the positions (5 for G1 FOUR). This occurs when there's a "wide" module in the chain. To work around this bug, setup the chain with "narrow" modules, then assign the "wide" modules into the intended positions by replacing the "narrow" modules.

Roseweave commented 1 year ago

Have people figured out how to load Wide effects on the B1/G1x Four yet?

nomadbyte commented 1 year ago

... it's possible to load "wide" effects into all of the allotted 5 positions in the chain (thus with 5*2=10 total page count). However, in practice this would be restricted by the available DSP Load.

Well, looks like it's a ToneLib UI related behavior. The actual pedal's firmware (G1 FOUR) does not allow the operation of more that 2 "wide" (8-param) effects in the chain; it allows assignment of wide effects into all 5 positions, yet only 2 of them will be functional, the other ones will be flagged with exclamation point (DSP overload warning).

Yet 2 "wide" and 3 normal effects in the patch chain will be all functional (provided the DSP load is below ~92%).

So, with G1 FOUR and similar it looks like there's allowance for up to 7 active "slots" (22 + 31); each "wide" effect takes up 2 slots. Curiously, this yields max 28 parameters (7*4), like 7 of those mini-screens with four knobs each.

I wonder if this limitation is rather artificial (for GuitarLab UI purposes) and the pedal's DSP hardware itself is capable to operate "wide" effects in all of the 5 positions in the chain (up to the DSP load capability).

nomadbyte commented 1 year ago

...the pedal's DSP hardware itself is capable to operate "wide" effects in all of the 5 positions in the chain (up to the DSP load capability).

Confirmed. The G1 FOUR pedal hardware is well able to operate the 5 wide effects in the chain. Attached is a photo with the same chain of effects as was shown above [FD TWNR => 3xGt GEQ7 => BG MK1], DSP load: 84%.

g1four-5-wide-effects

nomadbyte commented 7 months ago

@shooking: If you've a chance, could you also check the G5n output from the following SysEx commands?

0x55: f052006e55f7 0x44: f052006e44f7 (0x64, 0x0a): f052006e640af7

If you have G3n (emulated on GCE-3 is ok), it'd be nice to see the output too, to compare.

nomadbyte commented 7 months ago

@mungewell: If you still have the GCE-3, maybe you could try getting the output from the 0x55 (model info), 0x44 (bank info), and (0x64 0x0a) (settings info) SysEx commands while in the G5n and G3n emulation mode? All of these commands are queries, that is they should not change any settings. I have the outputs for the G1 FOUR and need output from other models to make sense of it.

mungewell commented 7 months ago

Sure do... is this what you wanted?

GCE3-as-G5n

$ amidi -l
Dir Device    Name
IO  hw:1,0,0  ZOOM GCE-3 

$ amidi -p hw:1,0,0 -S 'F0 52 00 6e 55 00 00 00 00 F7' -r temp.bin -t 2; hexdump -C -v temp.bin

96 bytes read
00000000  f0 52 00 6e 54 01 00 00  00 00 01 00 00 00 00 00  |.R.nT...........|
00000010  00 00 00 00 00 01 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  00 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  00 00 00 00 00 00 05 f7  |................|
00000060

$ amidi -p hw:1,0,0 -S 'F0 52 00 6e 44 00 00 00 00 F7' -r temp.bin -t 2; hexdump -C -v temp.bin

30 bytes read
00000000  f0 52 00 6e 43 48 01 78  05 48 01 04 00 02 00 00  |.R.nCH.x.H......|
00000010  00 00 00 00 00 00 00 00  00 00 00 00 00 f7        |..............|
0000001e

$ amidi -p hw:1,0,0 -S 'F0 52 00 6e 64 0a 00 00 00 F7' -r temp.bin -t 2; hexdump -C -v temp.bin

19 bytes read
00000000  f0 52 00 6e 64 09 75 00  01 01 05 00 00 01 00 32  |.R.nd.u........2|
00000010  06 00 f7                                          |...|
00000013

$ amidi -p hw:2,0,0 -S 'F0 52 00 6e 48 00 00 00 00 F7' -r temp.bin -t 2; hexdump -C -v temp.bin

22 bytes read
00000000  f0 52 00 6e 47 01 00 00  00 00 01 00 00 00 00 00  |.R.nG...........|
00000010  00 00 00 00 09 f7                                 |......|
00000016

mungewell commented 7 months ago

Sure do... is this what you wanted?

GCE3-as-G3n

$ amidi -l
Dir Device    Name
IO  hw:1,0,0  ZOOM GCE-3 

$ amidi -p hw:1,0,0 -S 'F0 52 00 6e 55 00 00 00 00 F7' -r temp.bin -t 2; hexdump -C -v temp.bin

96 bytes read
00000000  f0 52 00 6e 54 01 00 00  00 00 01 00 00 00 00 00  |.R.nT...........|
00000010  00 00 00 00 00 01 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  00 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  00 00 00 00 00 00 03 f7  |................|
00000060

$ amidi -p hw:1,0,0 -S 'F0 52 00 6e 44 00 00 00 00 F7' -r temp.bin -t 2; hexdump -C -v temp.bin

30 bytes read
00000000  f0 52 00 6e 43 16 01 78  05 16 01 03 00 02 00 00  |.R.nC..x........|
00000010  00 00 00 00 00 00 00 00  00 00 00 00 00 f7        |..............|
0000001e

$ amidi -p hw:1,0,0 -S 'F0 52 00 6e 64 0a 00 00 00 F7' -r temp.bin -t 2; hexdump -C -v temp.bin

19 bytes read
00000000  f0 52 00 6e 64 09 75 00  01 00 05 00 00 01 00 32  |.R.nd.u........2|
00000010  06 00 f7                                          |...|
00000013

$ amidi -p hw:1,0,0 -S 'F0 52 00 6e 48 00 00 00 00 F7' -r temp.bin -t 2; hexdump -C -v temp.bin

22 bytes read
00000000  f0 52 00 6e 47 01 00 00  00 00 02 00 00 00 00 00  |.R.nG...........|
00000010  00 00 00 00 07 f7                                 |......|
00000016

mungewell commented 7 months ago

BTW, do you know about the 'decode_screens.py' script. This gives a representation of what's on the device's screen.

nomadbyte commented 7 months ago

Thanks! That's the info I wanted. Can't say this makes it all clear but for sure it gives more details. Will be looking into the outputs.

Yeah, I saw the screens script -- great effort! The 'screen' basically joins the ZD2 parameters with their current values, so there is no need to separately parse out ZD2 or query it from a db -- the firmware does it nicely.

nomadbyte commented 7 months ago

For completeness

G1 FOUR:


amidi -p hw:1,0,0 -S "f0 52 00 6e 55 f7" -t 1 -r temp.bin ; hd -v temp.bin

96 bytes read
00000000  f0 52 00 6e 54 02 00 00  00 00 01 00 00 00 00 00  |.R.nT...........|
00000010  00 00 00 00 00 01 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  00 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  00 00 00 00 00 00 02 f7  |................|
00000060

amidi -p hw:1,0,0 -S "f0 52 00 6e 44 f7" -t 1 -r temp.bin ; hd -v temp.bin

30 bytes read
00000000  f0 52 00 6e 43 32 00 78  05 32 00 0a 00 00 00 01  |.R.nC2.x.2......|
00000010  00 00 00 01 01 00 00 00  00 00 00 00 00 f7        |..............|
0000001e

amidi -p hw:1,0,0 -S "f0 52 00 6e 64 0a f7" -t 1 -r temp.bin ; hd -v temp.bin

15 bytes read
00000000  f0 52 00 6e 64 09 75 00  00 00 05 00 00 01 f7     |.R.nd.P........|
0000000f

amidi -p hw:1,0,0 -S "f0 52 00 6e 48 f7" -t 1 -r temp.bin ; hd -v temp.bin

22 bytes read
00000000  f0 52 00 6e 47 01 00 00  00 00 10 00 00 00 00 00  |.R.nG...........|
00000010  00 00 00 00 07 f7                                 |......|
00000016

P.S. Updated (0x64 0x09) response to output BPM:117:(0x75 0x00) and Autosave:On:0x01 to be uniform with the other models above.

mungewell commented 7 months ago

This is what I thought the '0x44' message meant... https://github.com/mungewell/zoom-zt2/blob/master/zoomzt2.py#L483

nomadbyte commented 7 months ago

...This is what I thought the '0x44' message meant.

There's more detail in the output. It may deal with how to format the patch number. You may see that Guitar Lab shows patch numbers differently for these models, esp. for the G1 FOUR.

nomadbyte commented 7 months ago

Can you also dump the 0x48 command output for the G5n and G3n? It also queries some model details, apparently something like max number of patch slots.

mungewell commented 7 months ago

Can you also dump the 0x48 command

Added above.

nomadbyte commented 7 months ago

Thanks for the quick response! As we're at it now, could you dump the same 0x48 for G3Xn (the one with the pedal) and B3n, not sure if the GCE-3 supports these? Looks like there's some model id or the like in the byte[10].

model	SysEx:0x48=>0x47, byte[10]	1<<n
G5n	0x01	0
G3n	0x02	1
G3Xn	0x04	2
B3n	0x08	3
G1 FOUR	0x10	4

It appears to be the same values as in the PTCF patch files at the byte[16]. It is a kind of model id but specific to the patch context.

mungewell commented 7 months ago

GCE3-as-G3XN

$ amidi -l
Dir Device    Name
IO  hw:2,0,0  ZOOM GCE-3 

$ amidi -p hw:2,0,0 -S 'F0 52 00 6e 55 00 00 00 00 F7' -r temp.bin -t 2; hexdump -C -v temp.bin

96 bytes read
00000000  f0 52 00 6e 54 01 00 00  00 00 01 00 00 00 00 00  |.R.nT...........|
00000010  00 00 00 00 00 01 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  00 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  00 00 00 00 00 00 03 f7  |................|
00000060

$ amidi -p hw:2,0,0 -S 'F0 52 00 6e 44 00 00 00 00 F7' -r temp.bin -t 2; hexdump -C -v temp.bin

30 bytes read
00000000  f0 52 00 6e 43 16 01 78  05 16 01 03 00 02 00 00  |.R.nC..x........|
00000010  00 00 00 00 00 00 00 00  00 00 00 00 00 f7        |..............|
0000001e

$ amidi -p hw:2,0,0 -S 'F0 52 00 6e 64 0a 00 00 00 F7' -r temp.bin -t 2; hexdump -C -v temp.bin

19 bytes read
00000000  f0 52 00 6e 64 09 75 00  01 00 05 00 00 01 00 32  |.R.nd.u........2|
00000010  06 00 f7                                          |...|
00000013

$ amidi -p hw:2,0,0 -S 'F0 52 00 6e 48 00 00 00 00 F7' -r temp.bin -t 2; hexdump -C -v temp.bin

22 bytes read
00000000  f0 52 00 6e 47 01 00 00  00 00 04 00 00 00 00 00  |.R.nG...........|
00000010  00 00 00 00 07 f7                                 |......|
00000016

mungewell commented 7 months ago

GCE3-as-B3N

$ amidi -p hw:2,0,0 -S 'F0 52 00 6e 55 00 00 00 00 F7' -r temp.bin -t 2; hexdump -C -v temp.bin

96 bytes read
00000000  f0 52 00 6e 54 01 00 00  00 00 00 00 00 00 10 00  |.R.nT...........|
00000010  00 00 00 00 00 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  00 10 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  00 00 00 00 00 00 03 f7  |................|
00000060

$ amidi -p hw:2,0,0 -S 'F0 52 00 6e 44 00 00 00 00 F7' -r temp.bin -t 2; hexdump -C -v temp.bin

30 bytes read
00000000  f0 52 00 6e 43 16 01 78  05 16 01 03 00 02 00 00  |.R.nC..x........|
00000010  00 00 00 00 00 00 00 00  00 00 00 00 00 f7        |..............|
0000001e

$ amidi -p hw:2,0,0 -S 'F0 52 00 6e 64 0a 00 00 00 F7' -r temp.bin -t 2; hexdump -C -v temp.bin

19 bytes read
00000000  f0 52 00 6e 64 09 75 00  01 00 05 00 00 01 00 32  |.R.nd.u........2|
00000010  06 00 f7                                          |...|
00000013

$ amidi -p hw:2,0,0 -S 'F0 52 00 6e 48 00 00 00 00 F7' -r temp.bin -t 2; hexdump -C -v temp.bin

22 bytes read
00000000  f0 52 00 6e 47 01 00 00  00 00 08 00 00 00 00 00  |.R.nG...........|
00000010  00 00 00 00 07 f7                                 |......|
00000016

nomadbyte commented 7 months ago

Thanks for the dumps.

mungewell commented 6 months ago

On the 'target' ID byte in the patch/ZPTC files. I pulled a patch from each of the emulation modes of my GCE-3 to give a more complete list.

To me this does not look like a ENUM, but more like a Bitfield. Can a patch be made with 2 (or more) bits set to support multiple pedals?

==> A1FOUR_AG D-28   -1704382678561.zptc.dump <==
    target = 256
==> A1XFOUR_AG D-28   -1704382711460.zptc.dump <==
    target = 512
==> B1FOUR_Sans Clean-1704382620829.zptc.dump <==
    target = 64
==> B1XFOUR_Sans Clean-1704382647768.zptc.dump <==
    target = 128
==> B3N_Comp&Drv  -1704382514749.zptc.dump <==
    target = 8
==> G1FOUR_MS HiGain -1704382549329.zptc.dump <==
    target = 16
==> G1XFOUR_MS HiGain -1704382588972.zptc.dump <==
    target = 32
==> G3_Phazed    -1704382438466.zptc.dump <==
    target = 2
==> G3XN_Phazed    -1704382471003.zptc.dump <==
    target = 4
==> G5N_Phazed    -1704382399211.zptc.dump <==
    target = 1

shooking commented 6 months ago

...This is what I thought the '0x44' message meant.

There's more detail in the output. It may deal with how to format the patch number. You may see that Guitar Lab shows patch numbers differently for these models, esp. for the G1 FOUR.

Soz for delay. Some external issues to deal with. In my code I use the 0x44 as follows (see python zoomzt2_shooking.py)

        # how big is patch etc
        data = [0x52, 0x00, 0x6e, 0x44]
        msg = sniffMidiOut("sysex", data)
        self.outport.send(msg); sleep(0); msg = sniffMidiIn(self)
        d = msg.data
        self.numPatches = d[5] * 128 + d[4]
        self.bankSize = d[11] * 128 + d[10]
        self.ptcSize = d[7] * 128 + d[6]

        # write out pedal state
        out1 = open("model.dat", "w")
        if not out1:
            sys.exit("Unable to open FILE for writing")
        tD = {
                "model": self.model,
                "numPatches": self.numPatches,
                "bankSize": self.bankSize,
                "ptcSize": self.ptcSize,
                "version": self.version,
                "gce3version": self.gce3version,
                "maxFX": self.maxFX
            }

mungewell commented 6 months ago

Confirmed, this is a bit-field. But the check is done at the Guitar Lab, as I can actually upload any patch with my code.

Guitar Lab 'greys out' patches for the 'patch bank' list if they do not match the current pedal. But now we can set a patch with multiple of these bits set, and it will show available for any of those pedals...

    "targets" / Peek(BitsSwapped(Bitwise(Struct(    # Informational, does not rebuild
        "g5n"       / BitsInteger(1),   # 0x01
        "g3n"       / BitsInteger(1),   # 0x02
        "g3xn"      / BitsInteger(1),   # 0x04
        "b3n"       / BitsInteger(1),   # 0x08
        "g1four"    / BitsInteger(1),   # 0x10
        "g1xfour"   / BitsInteger(1),   # 0x20
        "b1four"    / BitsInteger(1),   # 0x40
        "b1xfour"   / BitsInteger(1),   # 0x80
        "a1four"    / BitsInteger(1),   # 0x100
        "a1xfour"   / BitsInteger(1),   # 0x200
        Padding(6),
        "b2four"    / BitsInteger(1),   # 0x10000
        Padding(15),
    )))),
    "target" / Int32ul, # pedal that patch is for
    "data" / Bytes(6),

I changed the '-t' flag to accept hex, to make it easier to combine values.

nomadbyte commented 6 months ago

Interesting. Though this is potentially applicable only to compatible models. For example, G1 FOUR uses 1U and 3S effects, unlike G5n/G3n. G1 FOUR obviously lacks the expression pedal like G1X FOUR etc.

nomadbyte commented 6 months ago

@mungewell : Can you also dump the SysEx:[0x60 0x11] and SysEx:[0x60 0x02] for G5n, G3n, G3Xn, and B3n? These seem to return details about the flash filesystem.

mungewell commented 6 months ago

GCE3-as-G5N

$ amidi -p hw:1,0,0 -S 'F0 52 00 6e 60 11 00 00 00 F7' -r temp.bin -t 2; hexdump -C -v temp.bin

29 bytes read
00000000  f0 52 00 6e 60 04 11 00  00 08 00 04 00 00 74 03  |.R.n`.........t.|
00000010  00 35 1c 00 00 02 00 00  00 00 00 00 f7           |.5...........|
0000001d

$ amidi -p hw:1,0,0 -S 'F0 52 00 6e 60 02 00 00 00 F7' -r temp.bin -t 2; hexdump -C -v temp.bin

66 bytes read
00000000  f0 52 00 6e 60 04 02 01  00 31 00 00 00 00 00 00  |.R.n`....1......|
00000010  04 00 00 00 00 04 00 00  00 01 00 00 00 00 00 7f  |................|
00000020  1f 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000030  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000040  00 f7                                             |..|
00000042

mungewell commented 6 months ago

GCE3-as-G3N

$ amidi -p hw:2,0,0 -S 'F0 52 00 6e 60 11 00 00 00 F7' -r temp.bin -t 2; hexdump -C -v temp.bin

29 bytes read
00000000  f0 52 00 6e 60 04 11 00  00 08 00 04 00 00 74 03  |.R.n`.........t.|
00000010  00 35 1c 00 00 02 00 00  00 00 00 00 f7           |.5...........|
0000001d

$ amidi -p hw:2,0,0 -S 'F0 52 00 6e 60 02 00 00 00 F7' -r temp.bin -t 2; hexdump -C -v temp.bin

66 bytes read
00000000  f0 52 00 6e 60 04 02 01  00 31 00 00 00 00 00 00  |.R.n`....1......|
00000010  04 00 00 00 00 04 00 00  00 01 00 00 00 00 00 7f  |................|
00000020  1f 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000030  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000040  00 f7                                             |..|
00000042

These appear to be the same as the GCE3-as-G5n, I think that the 'drive' contents does not change significantly as the operational mode is switch between units.

nomadbyte commented 6 months ago

Thanks! Real G1 FOUR shows this somewhat differently:

$ amidi -p hw:1,0,0 -S 'F0 52 00 6e 60 11 00 00 00 F7' -r temp.bin -t 2; hexdump -C -v temp.bin

29 bytes read
00000000   f0 52 00 6e 60 04 11 00 00 08 00 04 00 00 7f 01   ðR.n`...........
00000010   00 7e 05 00 00 02 00 00 00 00 00 00 f7            .~..........÷
0000001d

[0x7e 0x05] is 766=0x02fe, which seems to be number of 4KB blocks in the internal flash filesystem. From your GCE3-based output this would yield 3637 -- that would be too high of an actual G5n storage. So maybe it's a different value altogether.

SysEx:[0x60 0x02] result is the same.

mungewell commented 6 months ago

This is my G1Four, with everything possible removed.... Screenshot_2024-01-06_10-39-47

$ amidi -p hw:2,0,0 -S 'F0 52 00 6e 60 11 00 00 00 F7' -r temp.bin -t 2; hexdump -C -v temp.bin

29 bytes read
00000000  f0 52 00 6e 60 04 11 02  00 08 00 04 00 00 7f 01  |.R.n`...........|
00000010  00 7e 05 00 00 02 00 00  00 00 00 00 f7           |.~...........|
0000001d

And then, after pushing the default ZT2 and letting Guitar-Lab upload the ZD2's... usage is shown as 96%.

$ amidi -p hw:2,0,0 -S 'F0 52 00 6e 60 11 00 00 00 F7' -r temp.bin -t 2; hexdump -C -v temp.bin

29 bytes read
00000000  f0 52 00 6e 60 04 11 00  00 08 00 04 00 00 7f 01  |.R.n`...........|
00000010  00 7e 05 00 00 02 00 00  00 00 00 00 f7           |.~...........|
0000001d

mungewell commented 6 months ago

I installed the same ZT2 on the GCE3-as-G1Four, but Guitar-Lab didn't auto fill.... so I had to manually upload

$ cut -d ' ' -f 7 rebuild.sh | xargs python3 zoomzt2.py -I

And then the usage reports as 29%, so the GCE3 really does have that much more memory! Screenshot_2024-01-06_11-14-23

nomadbyte commented 6 months ago

Wow! Thanks for the experiment.

To summarize the findings:

SysEx:[0x60 0x11] does return the total number of 4KB blocks on the internal flash, bytes:[17:19];
GCE-3 appears to have 3637 blocks or about 14MB, while G1 FOUR only 766 that is almost 5 times larger;
In terms of usable space, GCE-3 flash filesystem capacity appears to be 2496 blocks or about 10MB, which is only 3 times more than G1 FOUR (754 blocks or about 3MB)

shooking / ZoomPedalFun

Max FX for a Pedal? #7