Hi,

can somebody please show me a clean and simple example on how to measure elapsed time between two events? Good if it is vanilla compatible too. I am trying to set up a basic gate to filter out fast triggering.

Cheers

@cfry This is the "standard" way to measure elapsed time between events:
To filter out fast triggering, however, I'd do it like this:

debounce.pd

thanks a lot! I am trying it out now. But how would I set it up in order to measure time between two clicks on the same bang object? Sorry for being slow...

@cfry The first example is already set up like that, on the second one you gave to replace the inlet object on the left with your bang, and replace the outlet with a bang to display it, or print or what have you. The patch is meant to be used as an abstraction so you can specify the debounce time as an argument, so here is how you'd use it:
debounce-help.pd

Note that this is just a spigot gate that closes for a certain amount of time and then opens again, it doesn't "measure" time between bangs but it just doesn't let them through if they are faster than the threshold. Hope it helps.

It most certainly help, thanks. Super smooth example. I was thinking in a different order it seems. The only problem I see now is that a bang is passed after the gate time is passed. I would prefer to filter out until bangs are less frequent.

@cfry This may do it: timegate.pd

@ingox Definitely the simplest way for bangs, the spigot version is useful for other inputs as well (floats, symbols etc).

@weightless Yes, this can also be used for other input types: timegate2.pd

They behave a little differently. If there is a rapid fire of inputs, the spigot version will let some through, the select version will only let inputs through after the fire has ceased.

@ingox Interesting, how did you test that? I wasn't able to reproduce it with the spigot version, it seems to work properly.

@weightless After the delay time, the spigot version will let one input through, no matter if the distance to the last one is long or short. The select version will only let input through if the distance is longer than the threshold. I think there are different use cases for these kinds of filter. Like the spigot version is filtering the output, in the sense that it makes sure that the output is not under the threshold, whereas the select version filters the input, in that only input can come through that takes place after enough waiting time. Anyhow, here is the test: debounce-test.pd

@ingox Thank you, very well explained and of course it makes sense now. I was thinking where did this debounce abstraction of mine come from, and I think it was for "slowing down" the output of a slider, although it was this version debounce.last.pd, which I then adapted to the one I posted previously. I think the version with select is most definitely the way to go for filtering out fast triggering.

@weightless Yes, my intuition was also that usually one would want to just reduce the input, not block it all together. But it seems to depend on the use case

Hi,
thank you for your input and help! timegate.pd is sort if how I pictured it and it seems to work great for me. There is absolutely a use for the debounce one too, so I will save that one.

I intend to use this function to reduce a jitter problem I have with using (real life) switches with the digital inputs of an Arduino (with pduiono). When the switch release from HI position to LOW I get additional HI triggers, it seems. I suspect that this is unavoidable hence the need for a jittergate.

My own triggate.pd was intended to work as timegate.pd, but worked as debounce.pd, but it was mostly luck I think. The key it seems is to really know how the timing flow of pd works. It seems lite timegate.pd (and other patches) can be so compact is because an object like |t b sends the bangs in a specific order, right to left. So at each trig for the timegate there is actually two operations for |realtime|: First it sends the time from the last reset, and immediately after it restarts the counter. I was trying to achieve this in different ways and I knew it should be a clean way of doing it!

Here is my try just for reference. I think it worked just because I happened to make the connections in the right sequence.
testing_triggate_example.pd

@weightless I suppose it is fun re-inventing the [debounce] and [block-bang] abstractions from extended....
...... should keep us going for a few years.
Don't misunderstand me...... I enjoy it too....
And often there are a good selection to choose from as they were doing the same as us even back in the early days......
David.

@whale-av It's been such a long time since I used extended that I don't even remember all that was available but I'm sure that 90% of the basic abstractions I've made over the last few years have been done already multiple times. I think It's a shame that there is no organised way to find externals and collections of abstractions, and perhaps a searchable index would be even better than externals coming pre-packaged with Pd. This would prevent us from having to reinvent a lot of wheels for sure.

one more thing, a logic one.

How do I set it up to only filter a quick 1 after 0, but not a quick 0 after 1?

Input and output will be either 1 or 0.

@cfry I'll give it a shot:
filter1.pd

@weightless I agree..... but I really don't know how it could be indexed considering the infinite possibilities in Pd.
I keep a copy of extended in a folder and just text search for likely "names". They were pretty well named in the olden days as the obvious name could still be used..... but there are still a lot of [same-sames]
The most fun now is building abstractions for vanilla to replace now incompatible objects from extended.
David.

@weightless
filter1.pd works well, thanks a lot! Going live tomorrow

@cfry Great, good luck with your performance!