@lacuna Well, I blame you for my continued, irrational curiosity . I usually don't care about efficiency and care more about code clarity, but your original proposed solution intrigued me because it was both arcane and minimal. Plus I'm not even sure how to implement something like motex/shuffle in normal imperative textual languages like c or Java (which is how I think, even when patching).

Thanks for the links, I'll check them out later.

@lacuna, so as not to junk up @Dizzy-Dizzy's topic, I wanted to continue investigating in a new topic. For some reason I woke up this morning with the realization that your [array random] strategy (and therefore my version of it too of course) doesn't guarantee complete n-element permutations--it only guarantees that there are no successive repeats within any rolling window (which may be what @Dizzy-Dizzy wanted, which is another reason to start a new topic). I think that [array random] strategy only works if you are successively removing elements from the pool until it is empty.

Check out this test of your most recent version:
1776427700402-randompermutations2.pd

You can see that the permutations after the first two aren't complete. Maybe that wasn't your requirement?

@jamcultur Yes, right click on any message and choose help. Look at the bottom left. Also click on [pd dollar-variables]

I don't quite understand @Dizzy-Dizzy's issue description, but I did notice that @lacuna's patch doesn't generate complete permutations after the first one. I think you have to add the excluded # back into the pool at the right point. Sadly, my way of doing that significantly spaghettis-up the patch, but maybe someone can find a simpler way to do the same thing.
lacuna permutation wo repetition.pd

I also wonder if it's not the worst idea to just generate random permutations and simply throw out the ones you don't like, e.g. ones that start with the same # as the end of the previous permutation. I've done that in my own work, especially when I think the sound is more interesting than the programming.

@lacuna Clever! That [t f b] is doing all the work!

@arseniy Maybe this will give you some ideas (I see that I left the knob part out, but you can probably figure that out)
tableToSliders.pd

I guess the key idea here is to set each slider's receive symbol to something that you can iterate on since you can already iterate on array values.

@arseniy How are you storing the dozen numerical values?

In Pd, if you implement a fade using [line~] into [*~], you get one that is linear in amplitude, which sounds like it starts out slowly and speeds up very quickly. If you put [dbtorms~] inbetween and adjust [line~]'s args, it sounds more like a constant fade and you could say it was "linear in dB" or a constant dB/sec fade. There's nothing exactly like that in either REAPER or Soundforge--their audio-tapered curves still speed up as they get softer. Automating the track fader in REAPER shows something similar. In the following snapshot, the automation line on the bottom track is controlling the track fader, and the vertical red marker lines mark the points where the signal drops another 6dB from the previous marker. See how the markers get closer and closer as the fade progresses? That means the fade is speeding up in terms of dB/s, despite being controlled by a straight line between two points.

Assuming that REAPER and SoundForge cater to the way the vast majority of people hear/use fades, the constant dB/sec fade must not be considered useful in most cases. If I'm right, why would that be?

@arseniy This happens to me when using Chrome--Edge works fine.

@Yar That sounds similar to the Pd help example I04.noisegate