[PD-dev] representing parent patch levels as args

[Hans-Christoph Steiner]

On Dec 9, 2008, at 3:37 AM, IOhannes m zmoelnig wrote:

> 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.

I think it should give a warning since it is similar to asking for a  
filename that doesn't exist.  Or maybe there should be something to  
represent that it didn't get a result, since it is difficult to test  
to see that nothing happened in Pd while trivially easy to respond to  
events.  This could be a second status outlet or maybe special keyword.

>> 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).

Hmm, that's a good point.  Perhaps just the numbers and names are  
enough.

> 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...

I think this is a good idea, but should just use standard Pd syntax,  
no need for anything special:

            [2 (
             |
            [+ $1]
             |
[canvas_name]

.hc

>
>
> gfmasdr
> IOhannes



------------------------------------------------------------------------ 
----

Man has survived hitherto because he was too ignorant to know how to  
realize his wishes.  Now that he can realize them, he must either  
change them, or perish.    -William Carlos Williams