@oid said:

because I have a fondness for languages which learning them is primarily about learning to work around their failings and quirks and vanilla pd provides that better than most everything else.

Agreed, and there's humor in those failings too. Pd's expressive poverty sometimes reminds me of one college homework exercise where we were asked to prove that 2 < 3 using only the axioms for integers and the definition of less-than. And that same poverty forced me to learn DSP more deeply than I would have otherwise.

@ddw_music said:

it should be different every time!)

One of my CS teachers would have disagreed because of issues like the OP is having. (He often argued that CS was in denial that it was engineering, not science--and he's rolling in his grave for my crappy paraphrasing) Instead of musical examples he would have cited Monte Carlo simulations used to expose bugs in code. How could you reproduce them (in order to study them) if the pseudo-random number sequence wasn't deterministic? It's about what's most useful.

@Maks Maybe try falling back to an earlier version of Pd?

@inum said:

For connecting the [rand~] and [maximum~] path to the [delwrite~] the way to go is using [snapshot~], right?

One way to go, yes. You could also use [noise~], [samphold~], [phasor~], and [clip~} if you wanted to stay in signal domain.

Is there any alternative way to do what this branch is doing using only control rate and no audio signals?

Sure, it will be quantized by the block size period though, which may or may not be an issue. {metro}->[random] with some range shifting and [clip]

@inum I dunno, I didn't do anything, it just came out that way! Pd 0.53.1 on Windows.

@ddw_music eh, worst case it'll just clip (as I learned by embarrassing myself on this forum)

Edit: doesn't even sound clipped to me
filterBank.zip

Edit 2: oops, I missed that each clone should only generate one random number and use it for freq, Q, and gain

@inum I was thinking that [zl group] isn't necessary if you consider its function in the larger context. It's just preparing a list of 8 random numbers to be arguments to [fffb~ 8]. In Pd, I'd instead make an abstraction that has some kind of resonant bandpass filter in it. When it's banged, it would randomize its freq, Q, and gain. Clone that 8 times and bang them all. That would cover everything from the [uzi] through [fffb~ 8]. I have a favorite [click~] translation that I'm dying to share, but you didn't ask

(@alexandros I just Google "max msp <object name>" for each object's doc page in order to maintain the illusion that I've used Max/MSP )

@oid said:

An application needs to be built with support for Jack...

So if that's true for Linux, then it seems likely that it's true for MacOS too.

Are all these Linux audio routing frameworks essential to having audio output on Linux, or do they just augment Linux's built-in audio capabilities? Do audio apps have to be written to output to each framework specifically, or are they decoupled by a generic API?

(Sorry, as the OP I feel entitled to drag the level of this conversation down to my level of understanding )

@whale-av Could be, but it's also my impression that you can't do audio on Linux without it (Jack). C'mon y'all, school me.