Problematic base patch: calm-generative.pd

I received the base patch above from a friendly stranger online and built upon it, adding vline~ envelopes to each tone to emulate bell strikes and routing the output through a stereo feedback delay network. However, I cannot seem to get rid of pops and clicks that make for a sort of zipper sound in the output. I've attached the original base patch, because that seems to be where the issue is resides.

I initially suspected clipping, but I've tried reducing tone amplitudes with *~ and modifying line parameters to no avail. Changing Audio Settings -> Latency to 50 ms, 100 ms, or even 1000 ms doesn't have an effect either.

The patch is super sensitive to graphics changes for some reason, and it glitches out badly in edit mode when I move my cursor. I've always attributed that to a bug in my setup since I'm running Pd on a Debian Linux machine with PipeWire managing the audio. I had issues with native JACK as well. It's not a big deal, because the final version of the patch is a web app. But it might be relevant to debugging.

My biggest issue is that when compile the patch to WebAssembly using WebPd, the pops and clicks persist. It's actually worse in the web version. The feedback delay network can amplify the pops to a point at which they escape containment and won't even disappear with full dampening. This makes the patch unlistenable on web.

Any ideas?

I'm still a noob, so maybe I'm missing something obvious.

Below are some images of the patch. It's basically a bunch of LFO's driving each other to pseudo-randomly trigger sine waves at set frequencies. There are 14 total possible tones. The attached patch only has 8 of them connected to the dac~ output.

Single tone element with one LFO driver:

Full patch:

I didn't open the patch, but you don't want to multiply audio using message-rate ramp (from regular [line])
use [line~] instead
edit: I noticed you're also setting a [*~ ] from a [/ 2] (from the [snapshot~]) every 50 ms. That's probably also doing some popping. Maybe a [line~] over 50 ms instead would be appropriate? not exactly sure of the intent there

@waffles On Windows 10/Pd 0.55.2, this patch somehow prevents me from switching between windows or accessing the taskbar, except when task manager is open. I'm guessing it's related to the fact that all the bangs hanging off of the [sel 0]s are solidly on, suggesting that the patch is falling behind in the control domain and perhaps missing realtime audio deadlines in the audio processing. That would definitely cause clicks.

I also notice that the connections coming from each of those same bangs are not explicitly sequenced with a trigger object. I'm assuming the author intended [line] to jump to 1 first, which could also be a source of noise due to the discontinuity. Even if you took @seb-harmonik.ar's suggestion to replace it with [line~], that discontinuity would still be there.

If I could somehow get this patch to let me edit it, my first experiment would be to cut out most of the repetition to see how various subsets behave. I think that would give me a lot of information about why the patch is making so much noise.

Edit: just learned about the -noloadbang flag. <other silly BS deleted >

Another edit: Let me know if this works better for you--this version doesn't freeze my computer. calm-generative 4.zip I replaced the loadbang with a toggle so it wouldn't start immediately. I added abstractions for each LFO and each AR oscillator to help me see what was going on. The latter lengthens the attack to 20 ms (from 0) and also controls the final volume using the LFO signal itself, rather than the one sampled every 50 ms, in case that was the cause of the zipper noise you were hearing. I deleted the oscillators that weren't connected to the dac in case they were eating CPU. It should be easy to add them back in now that you have the abstractions. I combined all the metros into one in case it helps reduce the control rate processing, and in an earlier version I staggered the bangs by 2 ms, but that didn't seem to make a difference. Finally, I noticed some light, occasional clipping, mostly in the left channel, so I halved the signal.