Hi,
I have a problem with trying to use both analog ins and digital outs and ins at the same time.
I have not found a firmata that works for both. I must be missing something obvious? :/

@whale-av cool, need to try the hardware solution next round. Great article!

@whale-av Hm, I get the picture. Then it should be easier to use an Arduino connected to the pi I understand. Would Pduino and Purr Data work on a pi?

(What I need to do in the input side is measure the conductivity/resistance of people)

@arpPDpi
Yes, that seems like an possible even better solution. I have so far only made a few simple programming tests on the Arduino and in this case I use the Firmata firmware, so I figured trying to add a debounce function to it would be too bold.

But maybe it would not be that complicated?

Hi,

I have heard that it is complicated to get Raspberry Pi's general purpose i/o pins to work with Pd, to the point where one should try to find another solution. Is this really so? :/ Or, where can I find out about this?

Thanks.

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

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.

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

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.

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...