Hi,
I'm sure you will show me I'm wrong, but alone I can't see it (that's why I love this list).
Namecanvas is said to be deprecated (well in the doc it says "obsolete").
Now, when something is deprecated usually there is a replacement: something better, or newer, or safer, or more elegant, which does the same; while the concepts of "better", "safer" and "more elegant" are questionable, that of being able to do all that could be done with the deprecated thing should be a requirement that can be verified.
As far as I can see, using the names that pd automatically assigns to canvas DOES NOT replace all the uses of namecanvas.
Suppose that I create an abstraction, say "myabstraction.pd", and I want it (e.g. when a given input is received) to send itself a message to dinamically create an object. I can have a [namecanvas $0something] in it and so the message I would use would be
[obj etc etc( | [s $0something]
But how can I do this without using namecanvas?
This:
[obj etc etc( | [s pd-myabstraction.pd]
won't do the job, because it will send the message to *every instance* of myabstraction that exists at that moment, since they have the same name. So if I have 10 instances, I will create 10 objects in each instance!! Unless that is what one wants, of course.
In fewer words, the automatically assigned canvas name is not unique to an instance of an abstraction, while the name assigned with namecanvas can be.
So what is the "replacement" for namecanvas?
Bye M.
On Fri, Feb 09, 2007 at 03:12:58AM +0100, Matteo Sisti Sette wrote:
Namecanvas is said to be deprecated (well in the doc it says "obsolete").
There are a couple of things it is actually impossible (or very difficult) to do without namecanvas, so I hope it stops being considered obsolete, or an equivalent alternative is presented.
Best,
Chris.
chris@mccormick.cx http://mccormick.cx
Hallo, Matteo Sisti Sette hat gesagt: // Matteo Sisti Sette wrote:
I can have a [namecanvas $0something] in it and so the message I would use would be
[obj etc etc( | [s $0something]
Try:
[clear( | [s $0something]
That's why [namecanvas] is not the final word on the functionality it provides.
Actually I don't understand why people are so in love with [namecanvas]. In five or six years of using Pd, I've never written a patch with it.
When I rewrote nqpoly4 the only thing I changed besides cleanup was replacing [namecanvas] with a simple subpatch.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
On Fri, 2007-02-09 at 07:52 +0100, Frank Barknecht wrote:
I can have a [namecanvas $0something] in it and so the message I would use would be
[obj etc etc( | [s $0something]
Try:
[clear( | [s $0something]
That's why [namecanvas] is not the final word on the functionality it provides.
Could you explain a bit more about this? I can't see how it relates to Matteo's question.
Jamie
Hallo, Jamie Bullock hat gesagt: // Jamie Bullock wrote:
On Fri, 2007-02-09 at 07:52 +0100, Frank Barknecht wrote:
I can have a [namecanvas $0something] in it and so the message I would use would be
[obj etc etc( | [s $0something]
Try:
[clear( | [s $0something]
That's why [namecanvas] is not the final word on the functionality it provides.
Could you explain a bit more about this? I can't see how it relates to Matteo's question.
If you have a [namecanvas named-abs] in a patch, and then send a [clear( message to that namecanvas with [; named-abs clear( you will also delete the [namecanvas named-abs] object. Then you will you not be able to access this patch again, and additionally it's at least strange, that an object - [namcavas named-abs] - is in fact destroying itself here.
If however you just want to do some dynamic patching, a subpatch is just as powerful and it's much easier to handle. Just compare the old and the new nqpoly4: The newer one using subpatches is more readable, much less error-prone and much easier to extend or change (which led to variations like [polypoly])
I can only think of a small handful of usecases where [namecanvas] is actually necessary.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
On Fri, Feb 09, 2007 at 10:45:12AM +0100, Frank Barknecht wrote:
I can only think of a small handful of usecases where [namecanvas] is actually necessary.
Hi Frank,
I agree with you that most things can be done by dynamically creating a subpatch or something like that. Maybe we should define these occasions when [namecanvas] is neccessary so we can illustrate if we actually need it or not. I'll have a grep through my patches to see if I can do without it on the occasions where I've used it.
Chris.
chris@mccormick.cx http://mccormick.cx
Actually I don't understand why people are so in love with [namecanvas]. In five or six years of using Pd, I've never written a patch with it.
Can't think of everything I've done with it before, but dynamically resizing the GraphOnParent dimensions based on the arguments of a patch is one for which I'm unaware of any other possible method.
Hallo, Luke Iannini (pd) hat gesagt: // Luke Iannini (pd) wrote:
Actually I don't understand why people are so in love with [namecanvas]. In five or six years of using Pd, I've never written a patch with it.
Can't think of everything I've done with it before, but dynamically resizing the GraphOnParent dimensions based on the arguments of a patch is one for which I'm unaware of any other possible method.
Yes, that's the only one I can think of, too.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
-
Chris McCormick -
Frank Barknecht -
Jamie Bullock -
Luke Iannini (pd) -
Matteo Sisti Sette -
simon wise