A few years ago I made a convoluted patch (no pun intended) that outputs a single sample 1-valued pulse on each of its [outlet~]s sequentially in round-robin fashion in response to a positive transition on its [input~]. It's pretty gruesome so I don't want to post it here, but for the morbidly curious suffice it to say it's based on cascaded shift registers with the last stage fed back to the first stage and requires [block~ 8 1 1] to work reliably at 2500 Hz. Anyway, it behaves like this:

• positive transition seen on [input~] -> pulse first [outlet~]
• positive transition seen on [input~] -> pulse second [outlet~]
• positive transition seen on [input~] -> pulse third [outlet~]
  ...
• positive transition seen on [input~] -> pulse last [outlet~]
• positive transition seen on [input~] -> pulse first [outlet~]
  ...

Anytime I look at my code I gag. Does anyone in the esteemed readership of this forum have a suggestion on how to do this in a less offensive way? I don't care about the signal specifics of the inputs and outputs as long as they are at audio-rate and easily detectable within a constant number of samples. I would gladly accept consistent latency in exchange for efficiency and elegance. Extra respect if the number of outputs can be easily changed without dynamic patching.

@jameslo robin.zip

This catches a change of slope (increasing value of a signal).
The [lop~] delays one input of [expr~] by enough to detect the increasing signal.
The [hip~] ensures that only one sample is generated, and [clip] zeros the overshoot from [hip] ... -1 ....when the incoming sample is decreasing.
[edge] then detects the change for the counter [count] and does the shift register for the output.

There is a way to dynamically change sends without dynamic patching. I need to remember/find that.
The patch works at [block~ 1] except for [edge] and of course latency (block 64) is necessary anyway if you need real audio output.
Replacing [edge] with a signal rate objects (much like the top of the patch) would be great if there is a way to count the impulses and switch in the audio domain.

There is a chance though that the new [snake~] object could do the switching of outputs.
And I just realised that I haven't checked that the register shifts before the impulse arrives at the [throw~]........ it probably doesn't.... and so a [delay~ 64] .... probably 64...will be required before [throw~].
David.

like this? I don't think you'll be able to do variable # of outlets without dynamic patching (if you know of any abstractions that do so I would be interested)
round-robin.zip

@whale-av You drop back into control-rate at [edge~] so that limits the speed of the shift to 689 Hz whereas my stinky patch runs at 2500 Hz. Even at small block sizes, control-rate processing only takes place every 64 audio samples. Behold!
(hmm, that probably only proves that [bang~] has that limit, I'll keep looking for the test that gave me that impression)

So I think that any scheme that involves redirecting a send~ or throw~ isn't going to be sufficient.

@jameslo Yes, I know. How did you create a shift register in the audio domain?
Off to bed.
David.

@whale-av like this:

I was a hardware gofer in my 20s, so maybe this seems odd in 2024 but it's just like the ICs I remember from the early '80s. (RE 689 Hz, sorry to restate the obvious to you)

@seb-harmonik.ar Yeah, I think that's it, nice work.

Sorry for confusion about changing the # of outlets. I really meant "adding more outlets manually without a whole lot of effort". Yours is easier than mine, so you win that one too.

For those following along at home, round-robin looks like this:

OF COURSE it seems so obvious now that I see it!