On 08/10/2013 10:37 AM, Jonathan Wilkes wrote:
On 08/09/2013 08:01 PM, Miller Puckette wrote:
Well, if ia user really wants 32K receives of the same name, (s)he can have them - but most people won't want to do that. In contrast, you can't have 32K copies of an abstraction without hitting this problem - and the business of binding patches to names is only rarely actually used. So (I'm now thinking) Pd should make it easy to defeat that useless behavior.
So the problem doesn't happen with [s $0-loop]?
I mean [r $0-loop]
-Jonathan
-Jonathan
cheers M On Fri, Aug 09, 2013 at 07:11:02PM -0400, Jonathan Wilkes wrote:
On 08/09/2013 04:31 PM, Miller Puckette wrote:
Or... just limit the number of canvases that can bind themselves to a single symbol to a reasonable number (5 or so, settable by flag for back-compatibility if anyone cares).
What happens to Claude's test if you a) patch Pd to stop binding pd-abstractionName.pd, and b) put a [receive pd-abstractionName.pd] inside the abstraction that's getting massively replicated?
I'd hypothesize that you end up with the same or closely similar problem, no?
If so then messing with the abstraction name binding risks introducing bugs or breaking some strange but interesting patches, and doesn't solve the larger problem which becomes anxiety about [s]/[r] pairs or any other nonlocal connection objects inside abstractions.
-Jonathan
cheers M
On Fri, Aug 09, 2013 at 07:51:30PM +0100, Claude Heiland-Allen wrote:
On 09/08/13 19:42, Miller Puckette wrote:
There still could be situations where an abstraction has a sub-patch ("pd foo" for instance) - I'm not clear as to whether those namings should be supressed as well. It seems like a tricky problem - lots of people seem to use abstractions with only one instance and might be depending on the bindings.
Maybe the best fix would be to make pd_unbind() constant time (perhaps by storing bindings in a doubly-linked list instead of a singly-linked list) and be done with it, instead of hacking workarounds..
Claude
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list