I've created a few patches using tonelib that look just fine in ToneLib and sound just fine, but when I look at the patch chain display on my G5N I see one or two effects that have a triangle with an exclamation point in the center replacing the normal icon for the effect. And if I put the G5N into "Stomp Mode" I see "process overflow - change effect" error in the effect display, and the red LED indicated the effect is off. But it is not off - I can see it on in ToneLib and I can hear it. So should I be worried about this? Sounds like a G5N bug, but it does not seem to affect sound.
I'm not sure which effects are in the patch that you created. G5n firmware has a way to limit patch chain by the effects' defined DSP usage and internal composition. However, ToneLib is more liberal in this, only limiting by the DSP usage. My guess is that if you tried to recreate your patch directly on the pedal, the G5n firmware would not allow the addition of some of the effects due to "process overflow". What you're observing is rather "by-design" of G5n firmware, not a bug. You may try to see if you can recreate this patch in the Guitar Lab, as it's ZOOM's own, unlike ToneLib.
Thanks. You are right that I could not create the patch directly on the pedal (and I am having issues with Guitar Lab, which is what lead me to ToneLib in the first place when I was looking for solutions to Guitar Lab problems). So, the G5N thinks what I programmed with ToneLib should not work, but it seems to work just fine, despite the annoying warning or error symbols in the LCD display. If "by design" G5N firmware prevents me making patches that work just fine .... seems like a bug to me. One of my patches with this symptom has the following chain: AcoSim - GrayComp - ParticleR - SlwAtkDly - CaronaTri - Hall - AnalogDly. ToneLib says DSP load is 72%. The G5N shows triangles with exclamation marks for the first 2 effects (AcoSim and GrayComp). And the G5N LED for those effects is off even though they look to be On in ToneLib. But the patch sounds fine and I can clearly hear the effects working (I can verify by turning them off and on via ToneLib, even though I can't turn them off and on via the pedal).
Interesting. My understanding is that individually these effects have Processor usage as such: AcoSim: 14% GrayComp: 22% ParticleR: 41% SlwAtkDly: 19% CoronaTri: 23% Hall: 12% AnalogDly 6% TOTAL: 137% ??!! I can't test this in the Guitar Lab with a G5n. Could you check the Processor usage % for each of these effects in the Guitar Lab?
I checked with both ToneLib and GuitarLab. ToneLib reports the "DSP Required" for each effect is AcoSim : 12.8% (GuitarLab says 13%) GrayComp: 20.18% (GuitarLab says 20%) ParticleR: 15.9% (GuitarLab says 38%) SlwAtkDly: 2.56% (GuitarLab says 16%) CronaTri: 7.81 % (GuitarLab says 20%) Hall: 11.8% (GuitarLab says 11%) AnalogDly: 2.2% (GuitarLab says %5) The total for ToneLib is 73.25% The total using GuitarLab numbers is 123% Note: I am using G5n firmware version 3.00 and GuitarLab version 7.3.1.130 and ToneLib version 4.3.1. I'm not sure where your numbers came from. They are closer to what GuitarLab reports to me, but still different. The numbers for ParticleR, SlwAtkDly, CronaTri are insanely out of wack. There must be a reason. I doubt very much that ToneLib and GuitarLab software are built with these numbers as hard coded constants. They must read them from the device or else they would not work when a firmware update adds effects, amps, and/or cabs. So there is something else funky going on if the two software packages read from the device the same way but report different numbers. I wonder if the amount of DSP resource for one effect can very depending on how you tweak its parameters? Maybe ToneLib is using a "nominal" value and GuitarLab is using a "max" value? Just a wild guess. Although I can see effects and patches using GuitarLab I can no longer save any changes I make. I can't even quit the app without it hanging. This is why I switched to ToneLib. GuitarLab worked for me for years but it does not any more. Maybe a Windows 11 update conflict? Regardless, my patches created with ToneLib seem to work just fine even if the G5N says it overloads the processor.
Thanks for listing these Guitar Lab values. The values I listed above are for G1 FOUR variants of the effects. Generally, the Processor usage info is encoded in the effect module file. However that number is scaled per given pedal model; assuming the higher end models have higher processing capacity. That's how the Guitar Lab is doing it. On the other hand, ToneLib is likely using hard-coded values. That's why there is this discrepancy. What is at play here is that ToneLib allowed to craft a patch with "firmware-defined" usage over 100%. And what you're saying is that the pedal hardware can cope OK with processing a signal with such a patch. That means that hardware capacity perhaps is higher than "defined" capacity. After all G5n is the flagship model. This ToneLib "bug" sort of helps users like you to be able to use such uber-patches I don't know how the encoded value is defined. Is it a current draw or some internal measure of processor load? I believe that for Multistomp pedals the enthusiasts likely derived these limited values empirically by combining various effects until the pedal says it's DSP Full, then further refining the resulting numbers. Probably something similar could be done by measuring the current draw but I don't know if anyone tried to to that. Also this does not give you the internal logic of how the firmware limits the capacity, as other parameters may be used too.
I tried and experiment using ToneLib to create a patch that would exceed what it thinks the capability of the device is. It simply refuses to add the device and displays an error dialog saying that the processing capacity would be exceeded. So the software does enforce what it thinks the limits are, even if it allows you to exceed the limits of what the device thinks it can do. Strange, and unexpected, but cool.
ToneLib has the necessary logic to limit the DSP load but the embedded numbers appear scaled with a fixed factor of 250, which in general should work OK with G5n, yet with G1 FOUR max out at about 90% instead of 100. Those values which are off have been likely hard-coded using older versions of the effects and not corrected for the newer versions. On the other end, ZOOM may have made some errors with the embedded numbers too. I don't know if it makes much practical sense to measure this usage empirically.
I'm surprised that ToneLib would have hardcoded numbers. That seems to imply it also has hardcoded knowledge of what effects each device has. But I know for a fact that, with various firmware updates, the G5N has added effects. So does that mean ToneLib can't control them until there is a software update for ToneLib? And what happens if this updated ToneLib that knows about newer devices is connected to an old G5N that has not had the firmware updates to add those devices? Especially since the same ToneLib supports so many different Zoom devices, I fully expected it to be using some API supported by the device itself that allowed the software to discover what it supported. I don't know this. But for someone who has been working with embedded systems and software for many years, it certainly seems like the most obvious way to design these systems.
I don't know the exact ToneLib implementation, it may be some combination of hardcoded metadata and dynamic access. There is some list of effects defined per model, icon pictures, parameter data etc. Even though most of that is also embedded in the effect's module, ToneLib needs to have it available for those modules which are not currently installed on the pedal. ToneLib can display it without internet. So it's reasonable to pack all this into the installed binary and maybe have some way to check/download the updates.