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 at mccormick.cxhttp://mccormick.cx