Frank Barknecht wrote
Try:
[clear( | [s $0something]
That's why [namecanvas] is not the final word on the functionality it provides.
I don't understand what you mean. If you mean because it makes PD crash, then try this:
[clear( | [s pd-whateverthisfileiscalled.pd]
with no use of [namecanvas]. This crashes too.
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.
The question is why people are so in love with sending messages to a canvas. I am not either. But if we admit that we "have the right" to send message to a canvas, then namecanvas is the only way to have (the main canvas of) an instance of an abstraction be assigned a unique name, not shared with other instances.
The workaround of creating a subpatch (which you may call $0- or $1-something) is ok if all the dynamically generated stuff is "processing stuff", but what if we are dinamically generating interface elements? It is not irrelevant to have to go one level deeper in the patch tree to get a piece of interface visible. I can think of real-life scenarios...
Hallo, Matteo Sisti Sette hat gesagt: // Matteo Sisti Sette wrote:
Frank Barknecht wrote
Try:
[clear( | [s $0something]
That's why [namecanvas] is not the final word on the functionality it provides.
I don't understand what you mean. If you mean because it makes PD crash, then try this:
[clear( | [s pd-whateverthisfileiscalled.pd]
with no use of [namecanvas]. This crashes too.
Well, that's an error of the patch-author. But clearing a patch containing a [namecanvas] doesn't crash Pd, it just makes the named canvas unavailable for further processing. Attached patch illustrates this behaviour.
The workaround of creating a subpatch (which you may call $0- or $1-something) is ok if all the dynamically generated stuff is "processing stuff", but what if we are dinamically generating interface elements? It is not irrelevant to have to go one level deeper in the patch tree to get a piece of interface visible. I can think of real-life scenarios...
Well, as I mentioned, this is one usecase for namecanvas, that's not possible with subpatches. But it's a usecase, that not necessarily requires a namepatch-object, it is probably better realized with canvas-Properties similar to graph-on-parent etc.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
On Sat, Feb 10, 2007 at 01:01:48AM +0100, Frank Barknecht wrote:
Matteo Sisti Sette hat gesagt: // Matteo Sisti Sette wrote:
The workaround of creating a subpatch (which you may call $0- or $1-something) is ok if all the dynamically generated stuff is "processing stuff", but what if we are dinamically generating interface elements? It is not irrelevant to have to go one level deeper in the patch tree to get a piece of interface visible. I can think of real-life scenarios...
Well, as I mentioned, this is one usecase for namecanvas, that's not possible with subpatches. But it's a usecase, that not necessarily requires a namepatch-object, it is probably better realized with canvas-Properties similar to graph-on-parent etc.
Not if you want to do it dynamically. For example, I have a couple of abstractions which change their size, depending on the arguments you pass to them. An example is the game-of-life patch I made, which creates toggles dynamically for each cell, and sets the size of the patch to accommodate those toggles. Another example might be an envelope generation patch which the user can specify the resolution of. You might want a physically longer looking envelope abstraction for a longer envelope time.
Or maybe you're talking about something else? The namecanvas issue would be solved if each patch was given a default name like pd-$0 or somesuch.
Best,
Chris.
chris@mccormick.cx http://mccormick.cx
Hallo,
Chris McCormick hat gesagt: // Chris McCormick wrote:
Or maybe you're talking about something else? The namecanvas issue would be solved if each patch was given a default name like pd-$0 or somesuch.
That's what I meant: Instead of an object like [namecanvas] that can be deleted, an entry field in an abstraction's "Properties" menu would be more secure.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
On Sat, Feb 10, 2007 at 09:10:01AM +0100, Frank Barknecht wrote:
Chris McCormick hat gesagt: // Chris McCormick wrote:
Or maybe you're talking about something else? The namecanvas issue would be solved if each patch was given a default name like pd-$0 or somesuch.
That's what I meant: Instead of an object like [namecanvas] that can be deleted, an entry field in an abstraction's "Properties" menu would be more secure.
Ah yes of course, that's a great idea.
Chris.
chris@mccormick.cx http://mccormick.cx
Chris McCormick wrote:
On Sat, Feb 10, 2007 at 09:10:01AM +0100, Frank Barknecht wrote:
That's what I meant: Instead of an object like [namecanvas] that can be deleted, an entry field in an abstraction's "Properties" menu would be more secure.
Ah yes of course, that's a great idea.
yes really. why has nobody suggested that before?
mfa-r IOhannes
-
Chris McCormick -
Frank Barknecht -
IOhannes m zmoelnig -
Matteo Sisti Sette