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

@fishcrystals said:

too expensive to use with [clone].

Might be obvious, but you only need one final anti-aliasing lowpass filter for all the upsampled clone-instances.

[clone] also just really does not like any reblocking (closing the patch while its running will often crash

I can not reproduce this. Pd 0.54.1 Win10

or some maths to try 8x or 4x oversampling to smooth out high pitches?

Modify J07.oversampling.pd to do any oversampling-factor.

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

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)

And [tabread4] and [tabread4~] do Lagrange 4-point interpolation.

If it has to be exact, this helps: https://forum.pdpatchrepo.info/topic/14301/add-delete-guard-points-of-an-array-for-4-point-interpolation-of-tabread4-ect

And [cyclone/wave~] has more implemented, such as cúbic, spline, Hermite

@mt2002 what is the error message?

@navu this could be another simple Vanilla speedlim:

GUI slows down when being updated at high rates.
This already might happen with a single GUI. Visuals / eyes do not require such a high update rate as sound / ears does. (PAL framerate is 25 fps)

so Pd can freeze with

[x]
|
[metro 2]
|
[o]

while metro 60 runs smoothly.

Without knowing your patch, into the dark: Separate GUI updates (with [set $1( message to GUI object) from audio modulations [*~]. Where GUI updates at lower rate.

[set( message makes sure the GUI is only set (here for visuals) without output.

First thing I try when dealing with fast incoming messages are [change] and some sort of [speedlim] before the GUI:
There are many different ones from different libraries, with the same name [speedlim], and some may be Vanilla abstractions, but not sure about this, - and as far as I remember, someone posted a simple Vanila speedlim in the forum just recently?

https://deken.puredata.info/search.html?libraries=&objects=speedlim&descriptions=

(wish Pd had build-in some kind of global speedlim for GUIs ...or would get rid of TCL)

@polle yes

also see the help file of s~ r~

the former way has been, and still useful:

[block~ 1]
[array define fb 1]

[tabsend~ fb]

[tabreceive~ fb]

not sure if [block~ 1] [throw~ feedback] [catch~ feedback] can go down to 1 sample delay, but I think so

On naming:
[pd nameofsubpatch] is a subpatch
and your [bbt-waveguide] is an abstraction

Also be aware that the patch is calculated in blocks
and if you detatch the feedback-loop with s~ r~ or similar,
one-block-delay is introduced in the feedback.
64 samples, - as long as you do not put these abstractions in a reblocked subpatch: [block~ 1] in [pd subpatch]

offtopic but all those 1-sample delays in the abstraction (one of many ways to do this in Vanilla would be [rzero_rev~] ) are not required I guess.