Hello everyone!
I am onsite working with a patch that will raise the amplitude on looped playback to rise when a drawer in a chest is opened, and quickly lower it when it is closed.
We have installed switches in the back of the drawers that are closed by the mechanical action of the drawer. There are 3 drawers total.
The switches that have been sourced for this are really 'noisy' when closed. When they are open they have a steady state that I can use, but when closed they are flickering 1 and 0 very quickly, and while it's working for the initial lowering of the volume, the subsequent on/off signal is making the audio flutter around, and over time, it can creep up quite a lot.
I've tried some debounce options I have used in the past for buttons, but they aren't working, while it does work in stopping all the on/off signals under a given amount of time, it also cut out the final one of those signals from the drawer/switch actually opening.
Can anyone offer some suggestions? Thank you!

hello

did you already search?
what have you tried that didn't work?

https://forum.pdpatchrepo.info/topic/12092/debouncing-was-measure-time-between-two-bangs-events

https://forum.pdpatchrepo.info/topic/14075/debounce-0-and-1-to-prevent-false-triggering/4

https://forum.pdpatchrepo.info/topic/11732/commands-for-forum-search-engine/2

I think the easiest is:

[route]
|
[t b f     ]
|         |
[del 150] |
|         |
[float     ]

or

[route]
|
[t f b]
| |
| [clear(
|/
[pipe 200]

both should be the same.

And better use

[line~] 
|\
[*~] 
|
[*~] 

[line~] for audio rate amplitude modulation (instead of 64-sample stairs with control-rate [line], which may sound noisy).
And squaring the curve for for that "logarithmic" amplitude-change (see also D04.envelope.quartic.pd)

but note that my [del] and [pipe] examples also make the start/stop more sluggish, might be ok for a drawer. @weightless example is more snappy https://forum.pdpatchrepo.info/topic/12092/debouncing-was-measure-time-between-two-bangs-events

@Dizzy-Dizzy on the EE side - sounds like you might not be interfacing to the arduino in an ideal way, normally you want to wire them pull up just using the arduinos internal resistors, putting a small capacitor across the switches will also filter out a lot of noise.

@lacuna thanks for these suggestions, and sorry all, I wrote that in kind of a hurry on my phone as the opening was that night! I have a bit more time to finesse things now.

The patch I had tried was 'timegate.pd' from this thread:
https://forum.pdpatchrepo.info/topic/12092/debouncing-was-measure-time-between-two-bangs-events/4

@lucuna the patch you suggested also seems to present a challenge: I need to ignore the fluttering 1s and 0s from the closed switch, but capture and use the last of these, which represents the actual opening of the drawer. After the switch opens, it is stableuntil it closes again, at which point the 'jitter' begins. I can conceptualize that it would be necessary to hold onto this final signal, wait until a reasonable amount of time has passed (long enough to know it's not part of the jitter of the switch, but not so long that the sound is triggered noticeably late) and then allow it through, but I can't see how to build it!

Thanks everyone for all your help.

@fishcrystals hi there and thanks. I have a startup message in the top left of the patch I posted that sets up the pins and switches on the pullup resistors, but it's not helping on these switches. Thanks for the capacitor suggestion, will bear that in mind!

@Dizzy-Dizzy said:

I need to ignore the fluttering 1s and 0s from the closed switch, but capture and use the last of these, which represents the actual opening of the drawer. After the switch opens, it is stableuntil it closes again, at which point the 'jitter' begins. I can conceptualize that it would be necessary to hold onto this final signal, wait until a reasonable amount of time has passed (long enough to know it's not part of the jitter of the switch, but not so long that the sound is triggered noticeably late) and then allow it through,

This is exactly what I thought and what my [del] and [pipe] examples do:
The delay restarts on each incoming bang, so it will output a bang after the switch has calmed down, steady at it's state.
If you set the delay to 150 ms, all bouncing can have a max interval between each bounce of <150 ms. As soon as there is no new bounce until 150 ms are up, it bangs.

Test its working:

[x]
|
[t b f     ]
|         |
[del 1000]|
|         |
[float     ]
|
[x]

Did you try it yet?

Did you [print] the output of [route] or read the Arduino serial data and is this why you are sure it being a bouncing switch issue?

Connect this to your [route 2 3 ...] and show us the print:

|
[t f b b]
|||
|[timer]
||
[pack]
|
[print]

Did you replace

[line]
|
[*~ 0.1]

by my suggestion?
Because in your patch

[0 100(
|
[line]
|
[*~]

is very noisy!

Putting a [change] between [route] and [moses] prevents from retriggering by repeated numbers.

... how big is the drawer? Is it easy to close the switch? Do we get the switching-point? Or is the bouncing caused by trying to close the huge old drawer, so bouncing is > 500 ms?

(Debouncing can be done in software. But if you are already thinking about changing the hardware, light-sensors might be better than switches. )

I appreciate all the advice: I did try some of your original suggestions but let me try and put all of them into action and I'll report back here. Thank you!

Also, I neglected to detail the actual gear I'm using, which was not helpful!

I'm running a raspberry pi with an arduino nano, hence the use f the pduino arduino object in the patch. The 3 switches are wire to the digital pins 2, 3 and 4 of the nano, with the internal pull-up resistors enabled on these pins.