@porres Here's a comparison with cyclone/urn. Both are generating 4 element permutations, but urn sometimes generates a permutation that starts with the same number that the previous permutation ended with. Setting shuffle's 3rd arg to 0.25 guarantees that won't happen with 4+ element permutations.
motex shuffle explanation.pd

I've always liked motex/shuffle because it allows you to specify how soon a repetition can occur when you generate a new permutation. See the third argument:

@mrsean I wasn't really suggesting you use it. I was thinking of posting my own solution to your problem (which uses both expr and expr~) but when I looked more closely I realized that it's almost the same as yours except all in audio domain.

@mrsean Is [expr] and [expr~] available in the heavy compiler?

@raynovich Did you try increasing the delay in your audio interface settings? On one of my patches that fixes the drop out after I create and destroy the gem window once.

I just got a fast new computer and I get a very short dropout on [create( but not [destroy(, so I guess that means "yes, that's just the way it is"?

I wonder if you put the GEM stuff in another process (using [pd~]) and you didn't return any audio from that process whether that would address this issue? EDIT: nope, it doesn't. And launching the subprocess is even more disruptive.

@rewindForward In addition to sharing your patch (it could even be one using [expr~]), please let us know what your trigger signal is (i.e. I'm unclear why the signal is ~1 ms long)

@whale-av I thought I had figured out the relationship between Q and BW but my patch failed miserably. So I just went with BW but got the same "close but no cigar" results:

Edit: looking back at that cookbook formula for notch coefficients (https://webaudio.github.io/Audio-EQ-Cookbook/audio-eq-cookbook.html), ff1 and ff3 are defined as 1/1+alpha, so the only way that could equal 1 is if alpha equals 0. But alpha is defined as sin(2 * pi * f / sr) / 2 * Q, so f would have to be 0 or Nyquist, or else Q is so large that it underflows the precision of the floats used to calculate the coefficients? And if it's the latter, then that seems like a weird thing to present as an illustrative example. (Note that in the example, f = 5512.5 = Nyquist/4--prob not a coincidence)

I'm still mystified.

In the help patch for [biquad~] there are coefficients for a very narrow bandstop filter centered at 5512.5 hz @ 44.1k or 6000 hz @ 48k. The filter's Q isn't stated so I thought I could reverse engineer it using those coefficients as my key but I can't seem to generate them exactly by using either my own coefficient calculator or the one from ELSE (bicoef2). I get close with a Q of about 3500, but I can't match all coefficients with a single Q value (I can't remember if the 1s are even posssible). Why would that be?
help coefficients search.pd

@april Check the order of coefficients to [biquad~]. I think the feedback coefficients come before the feedforward coefficients. Also check the sign of the feedback coefficients. According to this reference https://webaudio.github.io/Audio-EQ-Cookbook/audio-eq-cookbook.html (formula 4) they should be negative.

Edit: additionally, try adding triggers to the outputs of the [expr] objects to ensure each of the sub branches are being evaluated in the order you think they should be. Here's my version based on that reference: biquad notch coefficients.pd