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.

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!

@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!

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

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!

Hello forum!

I have built the following patch for an interactive performance in order to achieve the following:
Button 1 will record a sound each time, which will be assigned a unique name "recording%d"
Button 2 will playback the most recently recorded sound file
Once 4 sound files are recorded, Button 3 will begin playback of these files, sequenced to a backing track. When the backing track finishes, all playback stops. During playback, all sound is routed to be recorded as a new sound file, which is also given a unique name "party%d".
Button 4 is set up as a panic button, to end playback if it is started in error via a momentary press. If the button is help down for 5 seconds it shuts down the pi.

I had hoped that by including a project save function (triggered just prior to shutdown), that the patch would remember the number assigned for each subsequent "party%d" sound file. However, when the Pi is rebooted it reverts to zero, and begins overwriting the prior sound files. I designed the patch so that the "recording%d" files are replaced every time, but I want to save the "party%d" files.

How can I get the patch to remember and continue where it left off? IE, "party1.wav" & "party2.wav" were created last time the device was on and the patch was running, so this time, once the pi boots up and the patch opens, we need to start with "party3.wav" and carry on from there.

Apologies that the patch is messy, I am still learning!

@whale-av Hi David, just now getting around to this, I was crunching up against a deadline!

Yes, the upgrade to 0.54 does seem to have resolved the issues in my OP, no freezing at all.

I also downloaded 0.53-2 and it also seems to have resolved hanging issues, but it also has the same issues with externals not working and not showing on the browser. Is it common for an update to stop a whole swath of externals from working? This gives me concerns about future proofing my patches - is it best to just not upgrade?

Thanks so much!

@whale-av Hi Davids, thanks for your help on this!
I just downloaded Pd 0.54 but it seems many of the externals I have downloaded which were working in 0.52-1 are not working on 0.54, breaking my patches: for example the maxlib library, which is installed and has a path, but is not showing up in the browser.
Any suggestions on this? I've not had this happened before.

Hello all,

Running 'Pd-0.52-1-really' on a 2021 M1 Macbook Pro. When I need to change my audio preferences (namely my audio output device) in PD, I can select the output I need, but when I click 'Save All Settings' or 'Apply' the following happens:

• 'Audio off' switches to 'Audio on' in the main PD window (the DSP checkbox does not respond, it remains unchecked)
• PD freezes: clicking OK or cancel in the Audio Settings window yields no response, the window will not close via any means. Similarly, if I have a patch open this will also freeze and cannot be closed. I have found I can close the main PD window, but I cannot quit PD- I have to force quit via the finder.

Upon reopening PD it's a gamble as to whether the audio setting I changed has even been remembered. This is extremely frustrating and is rendering the software very unreliable and hard to use (especially as I use it almost exclusively for audio).

Also, if I skip the process of clicking 'Save All Settings' or 'Apply', and just hit 'OK', the audio settings window closes, but the program still freezes in the same way.

Additionally, I'm trying to open a patch that contains a load bang to start DSP, and this will also freeze the program.

Has anyone else experienced this, and can they suggest any solutions? Thanks!

@whale-av thanks as ever for your help
In the console I'm just getitng the name of the object followed by '... couldn't create'.
For example:
pix_buffer_read vid
... couldn't create
gemhead
... couldn't create

Thanks both - I downloaded the zip file and moved the files into my externals folder (replacing the Gem externals I already had) but Gem objects aren't able to be created, just a dotted outline. Any hints on this? Running Ventura 13.2.1. Thank you!