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