Peaks as a double tap tempo problems

I’m sending a double-tap from Ableton Live to both Peaks trigs inputs via my FH-2. Just two gates from a 2-note Midi clip playing just once. Peaks is in SPLIT mode, TAP functions with square outs, relatively short pulse as its role would be to deliver 2 clocks.
I just upgraded Peaks to 1.1 since it seemed to correct a bug when sending the same clock to both Trig inputs, which is precisely what I do. (In case you’re wondering, I’m doing this only because I’m lacking a multiple in my system, but also I think it could be nice to have the ability to freely finger-tap one of the 2 clocks).
It works erratically. Sometimes just perfect. Sometimes, the two outputs will be really different.

Also, it seems that manually trigger the clocks, with the trig buttons, is super accurate.
I think it’s only happening with the trig inputs jacks. Maybe it has to do with the algorithm that adapts to irregular incoming clock patterns, which I believe only applies to the trig inputs jacks ?

I’ll have a look, but I can already confirm that the code doesn’t make the difference between taps and triggers.

How long are the trigger signals?

They are “long”, as they are notes drew in a MDI clips. So probably longer as regular triggers. I’ll try limiting them to 10ms.

Tried with 10ms triggers or longer notes. Tried with 0/+10V, -5/+5V. Same thing.
I send the same trigs to both channels, they do not always output the same clock.

Just to make things clear: you’re sending two notes and that’s it, or the notes play in a loop?

And it’s the same output from the FH-2 multed to the two inputs of Peaks, or different output?

I’ll try to replicate this.

I’m sending two notes, not looping. Just “tap-tap”.
I am using two outputs of the FH-2, they respond to the same MIDI channel so they should output the same thing. one goes two Trig1, the other on to Trig2.

If it helps, I could make a video. The idea is super simple, though.

I dove into the code. My bad, the algorithm is different depending on whether the tap is received from the button and from the trigger input (I was mistaken by the fact that the Process function has a single gate_flags argument containing the stream of events, but events from the button are annotated distinctly).

If you tap from the button, the module measures the interval between the taps and sets it as the period of the LFO waveform, end of the story. There’s no averaging, two taps are enough.

From the trigger input, the module applies a pattern identification algorithm, which allows it to lock onto clocks with swings or to irregular patterns (say a loop of a short and a long pulse), but for this to work you need to send a continuous clock signal (for the module to “learn” what it should lock onto), not just two taps. With two taps, the module will attempt to lock onto a pattern with two repeated pulses, then some blank (whatever pause there was between the time you stopped and restarted the sequencer), two pulses, a blank, etc. Would it be possible for you to send a continuous clock from the FH-2 instead of two pulses?

To summarize, it’s a tap LFO if you use the buttons, but a clock-locking LFO if you use the trigger input.

I’ll check if I can add a special condition in the code so that at the second pulse received after a long pause, the pattern predictor is exceptionally disabled.

1 Like

Haha, this was my assumption.
I’ll try with a continuous clock. In fact, this is how my live session was working before I thought I’d integrate Peaks. But then I assumed it was better to just put two taps, as it’s called “tap”.
Hope it will work.
Otherwise, an option to just ignore the pattern recognition algorithm would be nice. (My main concern with a continuous flow is that it might, from time to time, make mistakes that would not happen with an internal clock just going on).

In case it helps, and because you could think “wait, you’re just overcomplicating” and come with a much better idea, here’s the context :
I am playing live shows with Ableton Live, one Live Set per song, so I have to switch songs, resulting in silence (for everything that comes from the DAW). I have some clocked delays (Chronoblob, Echophon) and a clocked Wogglebug and I want them to keep running at the same rate when the clock stops (when I load the next song) because I use the delays to fill the silence gap.

Oh, and thanks Emilie for checking this out !

From looking at the code (I need to take a Peaks out of the “museum” case to confirm!), the pattern prediction algorithm stores a history of 32 pulses, so if the module receives 32 or more equally spaced taps (programmed in a clip at the end of your song), it’ll continue running regularly after the 32th tap.

1 Like

Thanks, I’ll consider that if I hear some inconsistencies when I send an ever going clock.

So after a few tests, sending a regular, ongoing clock seems to work, and it catches the new tempo usually after 3 or 4 taps.
Echophon goes stupid once in a while, but rarely, and it has its charm, and it’s hard to tell if it’s Peaks assuming the tempo has changed or Echophon miscalculating the clock.
Anyway, I can live with this tiny amount of danger.