@dreamer Oh! My bad. My post was probably made irrelevant by your previous post anyway.

@ytt +1 to @Balwyn's idea, but I thought you were asking about how to eliminate the race condition whenever 2 or more valves are pressed at the same time.
trumpet valve control.pd

Edit: hmm, I probably overcomplicated things with the list tosymbol test. Maybe I should have converted the valve triplet to a number right away and then tested that instead.

@whale-av Hey! Don't you need to add the triggers on some of those outputs that have two connections? I'm sure your patch works because your instincts caused you to create those connections in the right order, but still!

@ArduinoPrints3D Yes, I think you put the clone start flag in the wrong place so that the clone numbering is really going from 0 to 15. Try [clone -s 1 voicecloner 16]

@c_c +1 to @whale-av, and you could also just fade out before changing the delay and then fade back in, e.g.
changing delay.pd
To demonstrate that it's actually doing something, delete the highlighted messages and choose a few more random delay times. Click click pop!

A long time ago I needed something that would toggle between 1 and -1 at audio rate whenever its input decreases in value (as would happen when driven by a [phasor~]). This is what I came up with:

The blocksize has to be small enough to accomodate the highest frequency toggling that you need to support.

I was convinced that this was the only way possible, and so was completely surprised when I stumbled across this:
flipflop2~.pd
Seems so obvious in retrospect!

Edit: OMG, I posted a similar solution 3 years ago and forgot about it. I'm now accepting nursing home recommendations.

@spluta Maybe try [pd~] and distribute them across several cores/processes?

@whale-av Thanks! While searching for [coords( documentation I stumbled across [goprect( buried in the dynamic patching help. It looks like it's relatively new and doesn't set the dirty flag.

And unless there's a difference in how canvases are messaged, then it seems like the answer to my original question is that the [namecanvas] way let's you send to any accessible named canvas in the patch, whereas pdcontrol is just for the containing canvas and saves you the trouble of having to name it. Other than that they seem equivalent.

I'm sending a [donecanvasdialog....( message to a canvas to resize its GOP. It appears that I can either use [namecanvas] to create a receive on a particular canvas, or I can use the [sendcanvas...( message with [pdcontrol]. Which one should I use?

@ben.wes I like your mouse click logic + clipping better because you can drag outside the control to make things maximum or minimum.

For anyone else is trying to understand your patch, I want to correct my faulty explanation. Firstly, there are 2 canvases in the GOP area, one is the grey background that fills it, and one is a smaller white foreground. This latter one receives messages sent to $0-cnv, not the silly thing I wrote before, and its configured size has to be 1 so that vis_size can go to 1.