I don't think closing a patch using its $0 could fix this:
"if a message sent to a channel has the effect of changing immediately the number of receivers for this channel, then Pd is likely to crash."
It would also be the case if sending to a $0 related channel I think ; while clearing a subpatch (aka dynamic patching) doesn't lead to this condition.

OTOH I really don't know why it seemed to be different in Pd-extended or older vanillas...



2017-09-29 10:26 GMT+02:00 Dan Wilcox <danomatika@gmail.com>:
I'm not really a huge fan of dynamics patching for this as simply open and close seems so much cleaner. That being said, I wish there was a vanilla way to close an open patch using it's $0, etc. That's more of a matter for my suggestions for a more general canvas info etc object...

The funny thing is that I never experienced this issue before, way back to the original system running in 2006. I think the difference is the hardware was slower, so the list might have been traversed before the patch was closed whereas now the patch closes more quickly while the message is mid-list. Or vice versa.

I haven't experienced this with Pd-extended either and have played many shows, including the one in Nov at the Pd-con. It's only with trying to adapt this setup to vanilla that I'm running into things. (Yes, I've still been using extended for some older sets but am transitioning now.)

Maybe this is something fixed in extended?

On Sep 28, 2017, at 12:00 PM, pd-dev-request@lists.iem.at wrote:

That said, I think that @Dan could use dynamic patching; I've just
successfully tested creating/destroying abstractions every 5 millis, while
the abstractions were forwarding a value updated every millisecond from
master patch, without any crash.