[PD] GUI toolkits and custom GUIs WAS: Integra Live 1.5 released

Bill Gribble grib at billgribble.com
Sat Jan 26 17:01:13 CET 2013


On Fri, 2013-01-25 at 19:30 -0800, Jonathan Wilkes wrote:
> So inside [blah] let's say I have this:
> 
> [r foo]
> |
> [print I_don_t_want_bob_to_trigger_this]
> 
> I share my [blah] abstraction with Bob, who creates a [blah] instance in the same
> patch where he has
> 
> [Click here to start my thing(
> |
> [s foo]
> 
> I suppose I don't know what "lexical hygiene" means.  But I think you have to have
> a way to explicitly state that "binding symbol foo applies to >this< canvas and all
> of its children, but not to any parents".  Do you have a way to do that without using
> the $0 kludge?

PD's behavior and the $0 kludge falls out of the design where there is a
single namespace for s/r targets.  It's a programming language where
there are only global variables.  This makes some things easy
(communicating with other patches) and some things hard (keeping things
private, duplicating code blocks without copies stomping on each
other). 

My design started from the presumption that all variables (names) are
local to a scope.  Each patch has its own "global" scope (which is the
default for new names), and can have named scopes within it.  This
sort-of follows a model of "lexical scoping" that you see in languages
like Lisp and Scheme where you can explicitly wrap a block of code in an
environment where variables just local to that scope are declared.  In
MFP, a layer (subpatch) or group of layers can share a scope just among
themselves, or can use the patch's global scope. 

Again, this makes some things easy (cut and paste of subpatches without
stepping on each other, management of names without $0-prefixes, knowing
that your abstraction won't interfere with someone else's) and some
things hard (broadcasting to every instance of a patch/abstraction,
listening in on message traffic internal to somebody else's
abstraction).

Back to your example: it wouldn't work as-is in MFP.  The [s] would have
to qualify the "foo" name, since it doesn't exist in the scope of the
[s].  Let's say I make a [blah] in the patch with the [s] and I name it
"blah_1".  The [s foo] would need to be [s blah_1.foo] for it to get
where you intend it to go.  If you made 2 [blah] instances, "blah_1" and
"blah_2", you would have to send to the one that you wanted the message
to go to. 

> There are also use cases for "binding symbol foo applies to all instances of
> >this< abstraction", and possibly "all instances of abstractions from >this<
> libdir" (though the latter may be overkill).

Yes, these are real use cases.  I'm still trying to work out which ones
are highest-value; you can't do either of these things in MFP right
now. 

Thanks,
Bill Gribble 

> 
> 
> -Jonathan
> 
> > 
> > At the same time, references to names that can't be resolved in the local 
> > scope do bubble up, so you can have more global names if you need them.
> > 
> > Thanks,
> > Bill Gribble
> > 
> > On Jan 25, 2013, at 21:27, Jonathan Wilkes <jancsika at yahoo.com> wrote:
> > 
> >> 
> >> 
> >> 
> >> 
> >>  ----- Original Message -----
> >>>  From: Bill Gribble <grib at billgribble.com>
> >>>  To: Jonathan Wilkes <jancsika at yahoo.com>
> >>>  Cc: Lorenzo Sutton <lorenzofsutton at gmail.com>; 
> > "pd-list at iem.at" <pd-list at iem.at>
> >>>  Sent: Friday, January 25, 2013 7:55 PM
> >>>  Subject: Re: [PD] GUI toolkits and custom GUIs WAS: Integra Live 1.5 
> > released
> >>> 
> >>>  On Fri, 2013-01-25 at 15:21 -0800, Jonathan Wilkes wrote:
> >>>>>  From: Bill Gribble <grib at billgribble.com>
> >>>>>  I am working on a pd-clone intended to explore a lot of the 
> > topics in
> >>>  this 
> >>>>>  thread.  It's not fully baked yet -- the biggest working 
> > patch is
> >>>  a biquad 
> >>>>>  filter designer with pole-zero and freq response plotting -- 
> > but
> >>>  I'm 
> >>>>>  particularly excited about the approach to namespacing and 
> > scope
> >>>  management, 
> >>>>>  which works a lot like hc describes.  Patches have a set of 
> > scopes
> >>>  which can be 
> >>>>>  mapped onto subpatches (represented as layers, not separate 
> > windows). 
> >>>  Name 
> >>>>>  resolution in send/receive elements works like you would want 
> > it to.
> >>>> 
> >>>>  How does scope work for abstractions?
> >>> 
> >>>  Well, every object in a patch has a name.  To find that object, the 
> > tree
> >>>  of patches and scopes is crawled upward from the site of the lookup. 
> > For
> >>>  example, the (equivalent of) [s "foo"] first looks in the 
> > scope of the
> >>>  [s], then the patch-global scope of the containing patch, then in the
> >>>  application global scope for the name "foo". 
> >>> 
> >>>  Dotted notation can drill down, so [s "foo.bar"] would try to 
> > find an
> >>>  object named "foo", then find "bar" in its 
> > patch-global 
> >>>  scope (or an
> >>>  object named "bar" within a scope named "foo" in 
> > the current 
> >>>  patch). 
> >>> 
> >>>  Does that make sense?
> >> 
> >>  I don't think I understand it.
> >> 
> >>  Let's say I have abstraction [blah].  I want [s foo] and [r foo] inside 
> > [blah] and
> >>  all of [blah]'s children to talk to each other.  Then I want to share 
> > my abstraction
> >>  with Bob who needn't worry about the send/receive names I used inside 
> > [blah]
> >>  because they are guaranteed not to conflict with anything he does outside 
> > the
> >>  scope of the [blah] abstraction (e.g., creating a [s foo] on the same 
> > canvas where
> >>  a [blah] object sits).
> >> 
> >>  Can I specify the scope of the s/r symbol in this way?
> >> 
> >>  Jonathan
> >> 
> >>> 
> >>>  Thanks,
> >>>  Bill Gribble  
> >>> 
> > 






More information about the Pd-list mailing list