[PD-dev] representing parent patch levels as args
IOhannes m zmoelnig
zmoelnig at iem.at
Tue Dec 9 09:37:25 CET 2008
Hans-Christoph Steiner wrote:
> On Dec 8, 2008, at 12:21 PM, Claude Heiland-Allen wrote:
>
>> Hans-Christoph Steiner wrote:
>>> So I am just adding support to canvas_name and window_name for
>>> getting the names from other canvases besides the current one,
>>> i.e. parent, toplevel, etc.
>> OK.
>>
>>> I am using the now standard numeric notation that is used in
>>> [getdir], iemguts, getdollarzero, etc.
>> Care to give a brief description of that for those that don't
>> know? I'd be interested in adding something similar to pdlua, so
>> that .pd_lua(x) files can access the path(s) of their containing
>> patch(es), would make sense to have the same numbers.
>
> 0 = current patch
> 1 = parent
> 2 = parent's parent
> etc.
>
> One question I have is about the behavior when you specific more
> levels than exist. Like [canvas_name 999999]. Should that be an
> error, warning? Should it give the toplevel? nothing? I am guessing
> it should give the toplevel, with a warning.
in iemguts it gives nothing and no warning.
however, you get an implicit, programmatic warning: no result from the
object means that the specified parent was illegal.
it is up to the user to print out an error message.
>
>
> Agreed, I think a limited set of names, like "parent", "toplevel" and
> maybe "current" just to make things explicit. I forgot I had already
> implemented this, except for the "parent" and "toplevel" part:
how's that done in tot? iirc something like "."?
which would give us:
.
..
/
but anyhow, i don't see a real reason for "current" and "parent" (but
have no strong opinion about the latter; the former seems much like an
overkill to me)
the only useful thing i could think of is "toplevel".
but then, the concept of "toplevel" is rather alien to me: everything is
patches/abstractions. i don't want my patch behave differently just
because i have created it as an abstraction within a toplevel patch
instead of a toplevel patch itself.
this is also the reason why i don't fully understand the concept of
[declare] yet (roman probably agrees with me here).
apart from that, i also have an idea to share:
how about the possibility to modify the parent-dept via arguments.
something like [canvas_name 2+$1]
(definitely not this syntax, it's just to illustrate my idea)
i haven't come up with a real use-case, though...
gfmasdr
IOhannes
More information about the Pd-dev
mailing list