...such as the H9
Some digital pedals also have an analog dry signal path so there effectively no latency on that portion of the signal. Depends on the pedal in question.
That's often the point, though. E.g., in a chorus effect. For others (reverb, delay), it doesn't matter.Yeah you can get comb filtering between the wet and dry if one is slightly delayed.
Yeah perception is a weird thing sometimes.
Always liked this one:
"In one recent test, psychologists asked 32 volunteers to sample strawberry yogurt. To make sure the testers made their judgments purely on the basis of taste, the researchers said, they needed to turn out the lights. Then they gave their subjects chocolate yogurt. Nineteen of the 32 praised the strawberry flavor. One said that strawberry was her favorite flavor and she planned to switch to this new brand."
On more than one occasion I've sat here subtly tweaking an EQ or Compressor plugin in a DAW track only to later realize I accidentally had the plugin bypassed the whole time. When the difference is subtle our brains can play some weird tricks on us.
After 6 pages, we've randomly stumbled across the topic this thread is actually about .Yeah you can get comb filtering between the wet and dry if one is slightly delayed.
was just checking my H9 which I use infrequently, and it actually (to my surprise though I always used 100% digital) does not have analogue dry thru - it does have a kill dry which kills the digital dry to make the digital fx 100% wet (assumes the user is routing analogue dry around the H9 in parallel)....such as the H9
if the sound coming through the speakers is not too loud, and you can hear the unamplified/acoustic sound of strings...it’s a different story.I'd wager that in a blind test, most players would be hard pressed to recognize any single digit latency difference.
It was improved after reporting it through tech support, roughly by 0.65 ms. My new results on 5.0.2:
in->out: 2 ms (down from 2.65)
in->amp+cab->out: ~3.35ms (down from 4 ms)
in->drive->amp->cab->out: ~4.07ms (down from 4.7ms)
Aside from a couple of obvious exceptions (look ahead compressor, drive, amp), no, adding blocks doesn't increase latency.Does latency increase with additional blocks (phaser, reverb, delay, PEQ, etc.) .... maybe even reaching a breaking point for some?
I think you are incorrect and the FM3 dynamically allocates processing power and latency is increased with added blocks. Obviously some will add significantly more than others.Aside from a couple of obvious exceptions (look ahead compressor, drive, amp), no, adding blocks doesn't increase latency.
I'll take a shot at this with some wild speculation...
I suspect that in order to minimise switching time and [many] other overheads... it isn't a case of 'oh, this newly selected preset uses a flanger, I'll create an instance of a flanger object' but rather that he instantiates all of the allowed instances of all the allowed block types in memory at power on and simply* switches the internal virtual wiring per preset. IOW, volatile memory constraints.
Well, that's my guess anyway.
[*] relatively simple... no dynamic destruction/creation of blocks required or memory management on a change of preset
I think you are incorrect and the FM3 dynamically allocates processing power and latency is increased with added blocks. Obviously some will add significantly more than others.
The only time I can see that latency would increase is if a preset is already pushing the CPU past 80%, to the point it's struggling to process its sub-processes. Processing the sound is the #1 priority, and the system WILL sacrifice other sub-processes ability to complete in order to keep the sound quality. That means updating the front panel and responding to knobs, and USB/MIDI and their talking to the editor will take a hit. Eventually, if the load is bad enough, the modeler begins disabling the blocks with the heaviest demands, again, to keep the sound flowing. If it's too bad, it will disable the sound so it can respond to the front-panel controls and the USB -> Editor connection in hopes that the user will pay attention to the flashing warning.I am only asking because when I run dual FM3s in parallel one surely seems to be lagging. I found this
thread where someone measured the latency of the FM3 relative to demands, and my reading of it was
that latency does increase relative to the demands of a particular preset.
No, adding blocks doesn't add latency (with a few exceptions I mentioned above). That's not how digital signal processing works. That's the very reason there is a cpu limit.I think you are incorrect and the FM3 dynamically allocates processing power and latency is increased with added blocks. Obviously some will add significantly more than others.
I mean...we have measured proof amp and cab blocks add latency, we all know pitch blocks will. I guess you are basing this off modulation/delay/reverb working by creating a secondary signal mixed into the primary dry signal? Yea...presumably that wouldn't add latency, but I believe any effect which is 100% wet would add some degree of latency.No, adding blocks doesn't add latency (with a few exceptions I mentioned above). That's not how digital signal processing works. That's the very reason there is a cpu limit.
ie: modulation fx have delays built in, so, @100% wet they will introduce latency due to the definition of the effect. Turn the delay parms down to minimum in a 100% wet mod block (ie "Min Delay" in Flanger, "Delay Time" in Chorus...) and latency will fall to almost the same as with the block off (those delays don't go all the way down to 0 so some small latency will always remain for these at 100% wet). At the same time, CPU will remain consistant with these blocks on or off since, as noted above, all blocks' CPU resource needs are allocated regardless of on/off.I mean...we have measured proof amp and cab blocks add latency, we all know pitch blocks will. I guess you are basing this off modulation/delay/reverb working by creating a secondary signal mixed into the primary dry signal? Yea...presumably that wouldn't add latency, but I believe any effect which is 100% wet would add some degree of latency.