Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Sometimes we need to a way to send messages to the current canvas or one of its parents. Currently, this is only possible if you know the symbol the canvas is bound to.
I see four basic ways how to implement this:
Are there more ways?
Personally, I don't care much because I use
No, not "as in 4". As I see it, this comment talks about getting a file name so you can send messages to it, not about setting a name with [namecanvas] (as in 4).
[sendcanvas] is merely a conjunction of [namecanvas] and [send], but it bypasses the need of setting a name. [sendcanvas] can also refer to a parent patch, and this is why I'm proposing [namecanvas] could do the same.
My main opposition here is with creating a whole new object (option 1). I think we can find a way to use an existing object.
yeah, I can't understand this one at all.
As for the others, I feel [namecanvas] seems the best candidate as it's closely related to [sendcanvas] and its purpose is exactly to allow communication to a patch. Therefore, if we include the functionality to talk to a patch with another object like [pdcontrol], then [namecanvas] becomes completely and actually obsolete.
Now, @millerpuckette seems to have thoughts on how [namecanvas] isn't that great. It's already placed in an 'obsolete' section of help-intro.pd, and the code said it ought to have been deleted (but obviously it won't be anymore). It's not really obsolete, though, it's just that there seems to be issues here I have no real idea, and I'm also assuming that it is a matter of the mechanism itself, not the object, meaning the issue will be there regardless where and how we implement this. So I'd like to hear from him.
I think you've misunderstood the comment. IOhannes talked about using symbols in general as a means of communication with a canvas. Actually, I don't agree with his assertion that canvas symbols are an implementation detail, e.g. they are required for working with data structures (see the
Just in case you're curious:
why is this a problem? it's totally ok for objects to become obsolete, see
I'd say it's the opposite:
Ok, seems then that "exposing an implementation detail" in a lower level is the only issue? Is there any 'danger' with this implementation? I can't see it.
Yeah, sending messages to Pd patches like that is common and even documented.
Well, never said the contrary, just wanted to note [namecanvas] + [send] is vanilla's way.
I kinda agree, I'd say is lower level, with no advantages for it that I can see. Maybe just use [send] objects in different places? But yeah, the design of [sendcanvas] seems nice, never criticized it.
I don't personally have problems actually. But I do think it's worth noting and I guess this is usually undesired and only pursued in Pd for more "extreme" cases.
The issue with [namecanvas] seems to be only about "dirty design". And well, I got many design options I prefer over vanilla (that's why I develop too many externals), but I think it's not an "extreme" case. Quoting @millerpuckette : "Adding features is how software inflates and eventually dies of bloat. One wants a valid use case before just adding stuff. And even then, if there's already a way to do the same thing, one should think twice."
So I'm trying to follow what I believe is the philosophy of Pd development, and then I'm thinking twice before ditching [namecanvas] and adding a similar functionality to another object.
Having said all that, I can take it back that adding [sendcanvas] is my main opposition, but it's not up to me :)
I have to say this feels dirtier and hackier and that it's my new main opposition :)