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!

@Il-pleut Can you expand on this? Saturated as in over zero?

@whale-av I had four buttons, so I changed up what they are controlling and have dedicated one for start and one for stop, which seems to have helped a lot. Adding the [change] object is also a great tip. Thank you!

This whole thread has been so useful, thanks all. I will be returning to it for future project also, when I have more time and I'm starting a bit earlier in the process.

@whale-av here's the inside of the debounce abstraction: I set the one on my 'record button a bit longer (400ms, on the left) to see if that would help... I seem to be getting 0 messages from the button before it is released, which cuts off recording too early, sometimes before any audio is even captured! Maybe I need to replace the button itself?

@60hz Thank you! By subpatches, do you mean abstractions? This will help? I thought the only benefit was to make things less cluttered.

@fishcrystals Thanks for the suggestions! I don't really have time for reinstalling patchbox but it looks awesome: I'm going to use it going forward. I've had a lot of audio issues with the regular raspian.
I tried booting to the text console but it negated the startup script I had in place using Autostart- I know there are alternatives to make the patch run on boot but I am under the gun here! Also, switching to text console meant I lost the ability to use VNC viewer, and I only have a teeny little screen to plug directly into the pi which makes things difficult to read.

@whale-av Thanks for all these resources! I added dwc_otg.speed=1 to boot/cmdline.txt... And maybe it worked? The glitch isn't consistent, although it is still happening. I have noticed that the buttons connected to the arduino nano may have become more jittery: is it possible this is a result of dwc_otg.speed=1 ?
The bang in the screenshot is actually because I took a screenshot of a screen recording that was paused. However, I have subsequently seen them stick when the glitch happens- it's as though the patch freezes for a period of time, and during that time the audio also gets stuck in that frozen way.
I've removed a bunch of those bangs since but it's still freezing intermittently.
I may have "intensively investigated" the patch but I'm still a noob, so could easily be missing something!

This sound clip demonstrates the glitch, just after 0:03, for about one second

glitch.mp3

Hello, I feel like I've been blowing the forum up recently, sorry if I'm coming across as needy

This seems like it would be discussed a lot online but I cannot find relevant advice on it despite some intensive searching.

I'm running a Pure Data audio patch on a RPi, with an external USB soundcard. The patch samples from an external microphone and plays back the sounds in a sequence to a beat. When this 'beat sequence' playback happens, it is routed and recorded as another discrete sound file. Recording and playback are triggered by buttons connected via an Arduino Nano and the pduino object.

As I've been working towards my deadline to finish the device and ship it, the patch has become more prone to a specific audio glitch where it freezes mid sound, kind of like a skipping CD. I've experienced this before on other projects but never this frequently! I would assume I am demanding more than I should of the RPi, but I don't feel like it's a particularly processing-heavy project.

Are there ways I can avoid this glitching/skipping/freezing, either by making changes within the patch or by somehow optimizing the way my RPi is set up and running? It's only required to run this patch, so I'm wondering if purging a load of unneeded software that came with the OS might help.

Here's the patch in case that is a useful reference (I have a few abstractions I've put in there):

Any advice gratefully received - I'm worried this won't be up to a usable standard if it keeps glitching out during use!

Thank you @fishcrystals I shall check this out. I didn't know this 'externals wrangler' existed!

Hi David @whale-av.

When I open an existing patch the externals in question are in a dotted line and I get the "cannot create" message in the console.

Also, as previously mentioned, despite the fact that there is a path to them in my preferences, a whole bunch of external libraries are not showing up in my help browser. They are showing in 0.52-1 but not in 0.53-2 or 0.54. These include Gem, ggee, pduino, zexy and many many more.

I shall experiment with compatibility settings- I didn't know that was an option. There's always some new function that surprises me, it's so cool!

Thanks as ever for all your help.

This worked great, thanks for pointing me in the right direction!