I can't quite put my finger on the HarPeggiator differences over the past few builds. Subjectively, I'm finding that the fuzz effects sound washed out, or tend to drop out.completely (on the individual fuzz "steps" in a given sequence). In fact, all of the effects sequences seem less "pronounced" (for lack of a better word). 3.0.0[19] installed.
Stereo setup in a series pedalboard configuration here, out to a rack mixer, and tested with a variety of sources. But I haven't eliminated all of the potential contributing factors. Apologies for the lack of of a reproducible recipe on this. Generalization at its finest.
A HarPeggiator filter / sync problem. I can only reproduce this with an external MIDI Clock [CLK IN: ON). Setting Tempo: OFF or CLK IN: OFF does not result in the following behavior:
HarPeggiator / Tempo: On / MIDI Clock In
Wet: 100%
Pitch Mix: A10:B10
Pitch A: ArpA:OFF
Pitch B: ArpB:OFF
Delay A: GrvA:OFF
Delay B: GrvB:OFF
Depth: ATK:0
Speed: 500 ms – 10 ms or Ln: 1/4 – 1/64 (see below*)
Xnob: FXA: RnFl (or any filter effect / all sequence)
Ynob: FXB: RnFl (or any filter effect / all sequence)
*I assigned the Speed parameter to an expression pedal, at maximum range from slowest to fastest, but I can get the same results by rapidly sweeping the physical Speed knob. Within a few full sweeps from minimum to maximum speed, the fliter sequences "stick". That is, the rate will audibly remain at 1/64 (10 ms.?); no matter what the knob position or display indicate.
A tap on the Play mode middle switch (RESTART) will bring the sequence rate back under control (by knob or expression pedal). Tap the encoder switch (Tempo: Off), then tap it again (Tempo back to On), and the garbling filters take off once againat a rapid rate.
I've tested this against several MIDI Clock sources, at varying BPM starting points. I have tried changing the source's BPM by 10, 20 or more, then back again. That won't bring the filter rate back under control. Only a RESTART, or switching away from tempo control will resolve it. I suppose it's possible that it's on the clock source end of the equation, but then why would an internal RESTART trigger prove to be the workaround fix?
