[PD] Calling a canvas names [was: Re: syntax of Pd files]
Hallo, Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote: On Wed, 17 Oct 2007, Frank Barknecht wrote: I think, one of the problems of [namecanvas] is that it's an object, and thus it can be deleted by a message. One suggested way out was to instead make namecanvas an actual property of the canvas, that is set through the props menu. tell me what should happen to [import] and [block~]... and if they have to be handled differently: why. As I see it, the only purpose of [namecanvas] is to allow sending messages to an instance of an abstraction and generally these messages involve some kind of dynamic editing. Building a network of objects on a canvas often is easier to make when starting from scratch with an empty canvas (because of connection numbering etc.). But you cannot clear the canvas when using [namecanvas]! This restriction leads to really ugly workarounds. Just compare the old version of nqpoly4 with the version, where I removed the [namecanvas] (which was unnecessary here anyway) and used a subpatch instead. If namecanvas was a property of the canvas, one could patch abstraction instances dynamically just like subpatches. Ciao -- Frank Barknecht _ __footils.org__ ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Calling a canvas names [was: Re: syntax of Pd files]
Hallo, Frank Barknecht hat gesagt: // Frank Barknecht wrote: As I see it, the only purpose of [namecanvas] is to allow sending messages to an instance of an abstraction and generally these messages involve some kind of dynamic editing. Building a network of objects on a canvas often is easier to make when starting from scratch with an empty canvas (because of connection numbering etc.). But you cannot clear the canvas when using [namecanvas]! Actually it occured to me that this is a silly argument, which I could only bring up, because I'm living proof that creating non-trivial Pd patches for 6 years is possible without ever using namecanvas once. It's silly, because of course one would normally not want to clear the main canvas of an abstraction altogether as that would also clear the logic to fill the canvas again, and this logic generally would be in the abstraction itself. This restriction leads to really ugly workarounds. Second silly argument: dynamically patching an abstracion instance would still be ugly even when namcanvas was a property, as you'd still need to keep track of how many objects your logic (see above) contains and you would not be allowed to change it. Ciao -- Frank Barknecht _ __footils.org__ ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
