Tap Tempo in GEN - wait for 4 'tap' presses.
Hi,
Im using the abstraction below for a GEN based Tap tempo counter, however I want to add the ability to only provide the result after say four taps, which would negate false button presses. Currently If I mistakenly press the tap switch it will immediately start recalculating. If it didnt get 4 physical taps it should not update and output its currently latched state.
Any tips or assistance would be great.
Thanks
AD

You could have the condition of the latch be accum -> [== 4] -> [change] -> [== 1] to open the latch for just the single sample of the 4th tap.
I'm not sure how your patch is actually computing the tempo though.
If you have 4 taps, then you probably want the average of the period between tap 1->2, tap 2->3, and tap 3->4. That means a) you need to measure the times between taps, b) add them up (and reset to zero when your accum resets to zero), and c) divide by 3.
First, I'd replace your [gtep 1] with a [>= 1], so your tap trigger is always 1.0. The amplitude of the tap doesn't matter does it?
Measuring time between taps you can use an [accum 1/samplerate @resetmode pre], which will count in seconds. Send the actual tap spike [>= 1] through a [history] into the accum input to reset after each tap.
Multiply the output of this the [>= 1] to get a single value when a tap occurs, and route this into another [accum] for the running total. (reset this accum the same way you did above, via [history] after the accum == 4)) Route that through a [/ 3] for the average.
That's maybe a good start. Tap tempo is actually quite a complicated thing to solve well though -- a simple method works OK, but a really robust tap tempo can be very tricky indeed. Have a look at delay locked loops if you feel like digging deeper.
Thanks Graham,
I got a little confused with your description but there were some hints that I could use.
What im actually trying to do is not have a accidental button press freak out the tempo (for live performance) , which is why I thought that having a count of four would help this.
Using hints from your description I came up with this which appears to work.

It assumes a count of 3 and divides the output by the same. Anything over 100000 samples counted (around 30 bpm in 1/4 notes) would be considered a mistake so it updates the history operator which I think resets the count? (probably doesnt but something is working :/)
I tried sending the out2 of the codebox to reset the accum but the patch cord didnt want to go there for some reason.
Thanks,
AD