zoom-zt2
zoom-zt2 copied to clipboard
mungewell
"DSP required" value per effect
I wonder if anyone has figured out where does a "DSP requirement" value per effect come from?
It could be seen in ToneLib per installed effect's properties. Also these values aggregate for all effects in a patch and the result is reported as "DSP Load" value (a percentage).
For example, for G1Four:
Patch 11: DSP Load: 65%
EP Stomp: 12.96%
MS 1959: 31.5%
ZNR: 4.35%
MS4x12GB: 9.2%
TapeEcho: 6.97%
---------------------------
64.99%
I'd guess this could be in a .ZD2 file but not sure how this is being encoded and at which offset.
Hi, It's a good question, and one that I wondered myself. That said I did not find where it (the CPU load) is stored.
As you suggest it's likely in the .ZD2 info. Which can be decoded/dumped using decode_effect.py, which uses this structure to define the format:
https://github.com/mungewell/zoom-zt2/blob/master/zoomzt2.py#L119
The overall load for a patch might also be included in the .ZPTC file, defined here:
https://github.com/mungewell/zoom-zt2/blob/master/decode_preset.py#L76
If you wanted to experiment, you could use decode_effect.py to dump the hex blobs for a number of different effects, and then see which bytes changed - and then match these up to the % reported in ToneLib.
I tried just matching the bytes for the percentage value but it's not clear in which representation it should be (int:xxyy, float:xx.yy, double:xx.yy, is the shown value rounded). It does not seem to match as either integer or floating-point value or even string: "xxyy", "xx.yy", "0.xxyy". Perhaps it's derived or packed somehow?
More progress on this puzzle. Looks like this value is sourced from the ZD2 INFO section: 4 bytes at the end of it, right before the start of the DATA section. The value appears to be encoded as IEEE-754 floating-point.
For example, for TAPEECHO.ZD2, float-val:17.43 (address:0x244, bytes:[a4 70 8b 41], hex-val: 0x418b70a4).
However, the ToneLib reported "DSP required" value for this effect is 6.97%, which is 17.43/6.97 ~= 2.5 times lower.
This 2.5 ratio (40%) mostly appears to hold for other effects/patches I checked. Yet, for a couple of effects the ratio is somewhat lower; for exampe:
MS4X12GB.ZD2, info-val:22.56, DSP-req:9.20, ratio:2.45
HALL.ZD2, info-val:27.07, DSP-req:11.80, ratio:2.29
There could be more discrepant effects.
It's not exactly clear, what is the meaning of that INFO field and what's the reason for such scaling but it's quite likely that this is (?one) of the source values for the "DSP required" effect property reported in ToneLib.
Any ideas about the "formula"?
| effect | info-val | DSP-req | ratio | % |
|---|---|---|---|---|
| EP_STOMP.ZD2 | 32.40 | 12.96 | 2.500 | 40.0 |
| MS19591U.ZD2 | 78.74 | 31.50 | 2.500 | 40.0 |
| ZNR.ZD2 | 10.87 | 4.35 | 2.499 | 40.0 |
| MS4X12GB.ZD2 | 22.56 | 9.20 | 2.452 | 40.8 |
| TAPEECHO.ZD2 | 17.43 | 6.97 | 2.501 | 40.0 |
| Patch 11 | 162.00 | 64.98 | 2.493 | 40.1 |
Good news, the x2.5 could be that it is a value out of 255 - rather than out of 100.
Construct (the 'language' used to define the blocks) as in built support for floats, you should be able to place a one line definition for the item: https://construct.readthedocs.io/en/latest/advanced.html?highlight=float#integers-and-floats
"dsp_load" / float32,
And remove the 4 bytes from next 'blob' to keep every thing aligned.
If you really wanted a % output, you can add percent_load / computed(dsp_load / 2.5). As to the subtle differences in value, perhaps that is not too important...
What's curious also is that in ToneLib the aggregated "DSP Load" for a patch remains fixed and does not depend on whether patch effects are On on Off. For example, Patch 11 has EP_STOMP Off, yet the patch "DSP Load" remains the same 65% even when it's turned On.
... the x2.5 could be that it is a value out of 255 - rather than out of 100.
This is unlikely, at least not on effect's level. As I showed above, most effects do consistently show the ratio 2.5; with 255 basis, the resulting "DSP reqired" values would be different.
Not sure if this ratio is dependent on the pedal's model, as higher-end models have support for more effects in a patch chain; G1 FOUR supports only 5 effects.
If anyone here has G5n (supports 9 effects) could you please check the reported "DSP required" values for the mentioned effects in ToneLib/Guitar Lab?
It would make sense to use the "maximum load", as you don't want the pedal to crash(/glitch) when you turn all the effects in a patch on. I have a GCE-3 at my other house, maybe useful for experimenting... when I can get my hands on it.
It's my belief that the extra sections for the .ZD2 are purely there for the convenience of the PC apps. I suspect that only the Code section is actually used by the pedal - some experimentation with switching/modifying the bitmap icon might prove this.
Also, note that the actual effect files between those of the G1Four, G5 and H8 are exactly the same. I mined them and computed MD5SUMs for each... https://github.com/mungewell/zoom-zt2/tree/master/zoom_fx
Where does the extra CPU power of the G5 come from, and why would more effects be possible? Is the 9 effects more related to the physical construction, with more screens? There are a couple of effect (ie Particle) which don't seem to run on the 'lesser' pedals, this could be related to linked libraries not available in the FW.
There is now a allZDL7.lst file (GuitarLab7 index) which includes more pedals and some audio recorders. I should do the same process on that.
My thinking is that if the pedal (or its config) allows more effect slots in chain, then this will allow for more of "DSP Load", which is aggregate of per effect "DSP required" value. G5n allows almost twice as many effects than G1 FOUR, thus by such calculation as in Patch 11, adding more of similarly "heavy" effects would bump the calculated "DSP Load" value to even closer to 100%, which won't be nice for users of the pedal to see.
So I believe the effect's "DSP required" values are scaled to reflect the perceived capacity of the specific device model. The scaling would be chosen to allow the prepackaged patches to "moderately" load the DSP. Well, just a speculation.
can the aux in be rerouted to have fx?
On Wed, Oct 5, 2022 at 10:43 PM nomadbyte @.***> wrote:
I wonder if anyone has figured out where does a "DSP requirement" value per effect come from?
It could be seen in ToneLib per installed effect's properties. Also these values aggregate for all effects in a patch and the result is reported as "DSP Load" value (a percentage).
For example, for G1Four:
Patch 11 DSP Load: 65% EP Stomp: 12.96% MS 1959: 31.5% ZNR: 4.35% MS4x12GB: 9.2% TapeEcho: 6.97%
64.99%
I'd guess this could be in a .ZD2 file, but not sure how this is being encoded and at which offset.
— Reply to this email directly, view it on GitHub https://github.com/mungewell/zoom-zt2/issues/46, or unsubscribe https://github.com/notifications/unsubscribe-auth/AOA5FJSFE47T3IICHSYQPGDWBWHXJANCNFSM6AAAAAAQ5UU7AM . You are receiving this because you are subscribed to this thread.Message ID: @.***>
Following up from my comment earlier, I parsed the effects from AllZDL7.lst and put the results here:
https://github.com/mungewell/zoom-zt2/tree/master/zoom_fx_AllZDL7
This makes a list exactly the same as before, however it's worth noting that 168 of the effects listed did not download for some reason... these are likely not seen before, and it's worthwhile figuring out how to get them.
Decoding the last 4 bytes of the INFO block.
diff --git a/zoomzt2.py b/zoomzt2.py
index b8e305f..6cec7f2 100644
--- a/zoomzt2.py
+++ b/zoomzt2.py
@@ -95,7 +95,8 @@ TXE1 = Struct(
INFO = Struct(
Const(b"INFO"),
"length" / Int32ul,
- "data" / Bytes(this.length),
+ "data" / Bytes(this.length - 4),
+ "dspload" / Float32l,
)
ie
$ python3 decode_effect.py -d zoom_fx_AllZDL7/G1\ FOUR/unzipped/TAPEECHO.ZD2
INFO = Container:
length = 20
data = b'\x00\x00\x00\x00DLYDELAY\x00\x00\x00\x00' (total 16)
dspload = 17.43000030517578
...168 of the effects listed did not download
Those effects seem to be specific for G6, B6, and G11 models, most of them have 88 suffix. The files may be in ZDLF7_2, I guess it's specific for GL 7.
Also curious is that for the G6, B6, G11 models there's ir_processload value defined in the AllZDL7.lst file.
| model | ir_processload |
|---|---|
| G6 | 83.00 |
| B6 | 86.00 |
| G11 | 105.01 |
Not exactly sure if it's more about "load" or "process", well, IR is about the impulse response, obviously. So assuming it's about load-capacity for processing the effects (which are modeled by their defined IR), then this value may describe the [??max] processing capacity of a given pedal model.
This, in some way, may be an equivalent of the "scaling factor", which translates the ZD2 defined value into the "DSP required" as reported.
In fact, this may just be the direct percentage factor. Similarly to G1 FOUR with supposed factor 40%. G1 FOUR supports only 5-effect chain, while G11 supports 9+1-effect chain.
@nomadbyte You were right about "ZDLF7_2" - this got me all the effects, and many were also updated revisions.
One thought on the processing power of effects, when comparing patches on different pedals ensure that the effect binary is actually the same. Or double check dspload is the same.
We already know that G1Four has effects which are customized for a single screen. It looks like the G6/G11 add another variant (unknown as to why).
For example:
0x040000a0 : MATCH30 (v1.10), 0x4e53b71acf5e94bfa85c648dd285e5a5
0x040000a1 : MATCH30 (v1.00), 0x1557365fe45e0153cdf59e4144474bdc
0x040000a2 : MATCH30 (v1.00), 0xd01bd654453b2648839acac29255f104
$ find . -name 'list_sorted.txt' -exec grep -Hi 0x4e53b71acf5e94bfa85c648dd285e5a5 {} \;
./G3n/unzipped/list_sorted.txt:0x040000a0 : MATCH30 (v1.10), 0x4e53b71acf5e94bfa85c648dd285e5a5, ./G3n/unzipped/MATCH_30.ZD2
./G5n/unzipped/list_sorted.txt:0x040000a0 : MATCH30 (v1.10), 0x4e53b71acf5e94bfa85c648dd285e5a5, ./G5n/unzipped/MATCH_30.ZD2
./G3Xn/unzipped/list_sorted.txt:0x040000a0 : MATCH30 (v1.10), 0x4e53b71acf5e94bfa85c648dd285e5a5, ./G3Xn/unzipped/MATCH_30.ZD2
$ find . -name 'list_sorted.txt' -exec grep -Hi 0x1557365fe45e0153cdf59e4144474bdc {} \;
./G1X FOUR/unzipped/list_sorted.txt:0x040000a1 : MATCH30 (v1.00), 0x1557365fe45e0153cdf59e4144474bdc, ./G1X FOUR/unzipped/MACH301U.ZD2
./G1 FOUR/unzipped/list_sorted.txt:0x040000a1 : MATCH30 (v1.00), 0x1557365fe45e0153cdf59e4144474bdc, ./G1 FOUR/unzipped/MACH301U.ZD2
./R20/unzipped/list_sorted.txt:0x040000a1 : MATCH30 (v1.00), 0x1557365fe45e0153cdf59e4144474bdc, ./R20/unzipped/MACH301U.ZD2
./H8/unzipped/list_sorted.txt:0x040000a1 : MATCH30 (v1.00), 0x1557365fe45e0153cdf59e4144474bdc, ./H8/unzipped/MACH301U.ZD2
$ find . -name 'list_sorted.txt' -exec grep -Hi 0xd01bd654453b2648839acac29255f104 {} \;
./G11/unzipped/list_sorted.txt:0x040000a2 : MATCH30 (v1.00), 0xd01bd654453b2648839acac29255f104, ./G11/unzipped/MACH30AU.ZD2
./G6/unzipped/list_sorted.txt:0x040000a2 : MATCH30 (v1.00), 0xd01bd654453b2648839acac29255f104, ./G6/unzipped/MACH30AU.ZD2
Thanks for the test.
In this patch G5n and G1 FOUR very much use the same ZD2 files, except for "MS 1959" effect. G5n loads "MS1959.ZD2", which has somewhat lower dspload value 77.92. This explains the lower Processor value 64% for G5n vs 65 (64.98)% for G1 FOUR.
Well, that leaves the question open for the proper naming and meaning of this value in ZD2.
Another look at the "scaling" could be that the ZD2 value is normalized by 250 and then multiplied by 100% to result in the "DSP required" value (EP_STOMP.ZD2: 32.40/250 * 100 = 12.96%). That is there's "something" that maxes out at 250.
Included 'DSP Load' in the --summary output, the winner (highest load) is
0x04080040 : MUDDY (v1.10, 47.30%), 0xf083665303d35b2db8ffe8f1f18a1ad1
very late to the party here - but excellent work by you both as ever
I wonder if the "scale factor" is real - that is Zoom kindly calculated that the G5n is much more powerful than a G1XFour.
Or if it is about reducing the perceived power of the device. IE maybe changing this in a ZD2 will report lower CPU and consume less.
I mean the GCE-3 can be all of the pedals ... is this a "super" processor compared to the other Zooms or just told that it can be more powerful?
... the ToneLib reported "DSP required" value for this effect is 6.97%, which is 17.43/6.97 ~= 2.5 times lower.
Just noticed, the 2.5 scaling factor apparently is ToneLib internal choice for G1 FOUR. However, Guitar Lab uses appears to use a different scaling factor: 2.3 for G1 FOUR. What's curious is that with such factor the ToneLib patch "maxes out" at about 90%. I guess, the 2.3 factor would bring the max DSP Load closer to 100%.
Not clear why this discrepancy is there. Maybe the 2.5 factor was applicable to some older Zoom pedals supported by ToneLib? The 2.3 factor should probably be applicable to MS series pedals.
More details on the reported DSP Processor use scaling factor.
First of all, apparently some DSP usage scaling data is reported back via Sysex: 64 11.
For example, G1 FOUR responds with F0 52 00 6E 64 10 66 01 04 01 00 F7.
[66 01]:(0x66 + 0x01*128) = 230
At this value, COMP.ZD2 effect reports 6% Processor Load in Guitar Lab. Changing this value to to, say, [22 01]: 162, results in 9% Processor use percentage for that same effect.
Now, we know that COMP.ZD2 contains the DSP "info-value" 13.94; applying to this value the scaling factor above as 13.94 / 230 = 0.061 = 6%; same with the different scaling factor: 13.94 / 162 = 0.086 = 9%.
So, this does support the previous statement about the DSP scaling factor 2.3.
Again, this is for G1 FOUR. Not sure what is reported back in Sysex: 64 11 for other "stronger" G Series models. Anybody to check this with G5n or B3n?
Also, it's not clear what is the meaning of the other values in 64 11 response (is it [04 01]: 132 ?) and if this is being somehow used in calculations of the reported DSP Processor use percentage.
Hi sorry for late reply - I should subscribe to see issues :-(
G5n & G3n
pi@ZoomPedalFun:~/Software/ZoomPedalG5n $ ./GetScaleFactor.sh
12 bytes read
00000000 f0 52 00 6e 64 10 7a 01 04 04 00 f7 |.R.nd.z.....|
0000000c
250
B1XFour
pi@ZoomPedalFun:~/Software/ZoomPedalG5n $ ./GetScaleFactor.sh
12 bytes read
00000000 f0 52 00 6e 64 10 66 01 04 01 01 f7 |.R.nd.f.....|
0000000c
230
No response from B1On.
@shooking Thanks! Is it from GCE-3 in G5n mode or the actual hw? I wonder if GCE-3 could respond to [64 11] for B3n as well.
above is from a real G3n and G5n. I dont have a B3n.
From a GCE-3 emulating a B3n
F0 52 00 6E 64 10 7A 01 04 03 01 F7
interestingly enough the last 3 returned HEX are different.
@shooking Thanks.
To summarize, the Sysex:[64 11] returns DSP-usage scaling factor:
F0 52 00 6E 64 10 (66 01):DSP-scaling (04 01 00):extra F7
| model | DSP-scaling | extra-bytes |
|---|---|---|
| G1 FOUR | 230 | [04 01 00] |
| B1X FOUR | 230 | [04 01 01] |
| B3n | 250 | [04 03 01] |
| G3n | 250 | [04 04 00] |
| G5n | 250 | [04 04 00] |
It's not clear what those extra bytes are. Looks like the last byte could be 01 for the Bass models?