@alexandros The Pi is not being restarted, no, although that could be one bandaid solution if I script a restart to reinitialize the patch after a defined period of time. A complete restart of the Pi is currently the only way to fix the issue. At the moment, the audio just ceases to work after a period of a few hours. Super weird. Oh, and I tried to remove the sleep flag but it seems to be a necessary delay for Pd to get up and running. I guess the OS needs time to get into shape to handle all things audio.

@whale-av I don't think it's a Pd issue either. The patch is still up and running, receiving data over a network from the Arduino, and general functional/editable but no dice on the audio front so it's likely that it's specific to Linux. Thanks for the pointer to ALSA resources/issues. I'll have a dig and see what I can find. I don't know if this has any bearing but I am using a little Behringer 2 -channel interface.

[sigmund~ notes] - give it a go! You could also try [sigmund~ pitch env] and use the latter for additional thresholding.

Hi, all. I'm curious: will the Xbox Kinect V2 work with this approach or is this the same deal as before where I need dedicated Windows hardware to do some tracking? I've been totally out of the loop on this stuff for years so I'm curious if anything has changed in that regard.

@Butahuruf Hey! Actually, I totally forgot that [sigmund~] has a notes flag that will report on any given note event instead of a continuous stream of pitch data. You should use that.

Cool. I like the sound of this project. I'd love to see a video!

@gmoon Interesting. Not sure on the conventions regarding zero padding - I thought switch~ took care of all that for you in Pd, no? It is conventional to have either an IIR or FIR depending on your needs in terms of latency and phase distortion. Not something I've really pursued in Pd either. lop~ should definitely hit the CPU less than vcf~, correct. vcf~, if memory serves, is better suited if you want access to real and imaginary parts but could be consider band and low-pass outputs respectively.

@Butahuruf Fun problem. You might start with the condition as you've laid it out by using the [expr] object and establish your triggering range using a simple if x > y && x < y statement. The tricky part is to only trigger the audio sample once (using something like [readsf~] rather than a bunch of times, so you'll also need to account for that, maybe using a [spigot] object to gate your triggering event. [onebang] and [once] existed at some point, too.

The easy answer my be the [threshold] object if it's still kicking around but start by breaking the problem down into modular chunks and sketch and test each one. Good luck.

Looks like @reboot sleep is merely a run at boot one time after 20 second delay. Any ideas why audio would cease after a few hours?

Hey @alexandros - question for you! So, after a while, running a Pd patch this way ceases to produce sound on my PiZero. I don't think it's because of how it's being run via crontab but maybe it's related to the sleep 20 parameter/argument? Task manager says Pd is still running. The patch (I think) is still receiving data from the Arduino but the CPU overhead would indicate that perhaps DSP is off or somehow this whole process is bypassed or idle/sleeping as the overhead is lower than when the patch is in full flight.

I'm not a Linux person so I'm not sure what kind of magic might be at work under the hood. Is there any reason why audio would stop working after a while? The PiZero is still functional, i.e., it hasn't frozen or crashed. Are there any commands that ensure the Pi doesn't take a nap?

Any guidance appreciated.