[PD] Should message objects be able to pre-parse $0 into valid dollarzero?

Ivica Ico Bukvic ico at vt.edu
Fri Sep 12 06:34:19 CEST 2014

On 9/11/2014 1:05 PM, Jonathan Wilkes wrote:
> Yes I agree the two ideas may coexist.  But I also think that if the 
> two were to coexist, $0 in message boxes would pale in comparison in 
> terms of usability.
> Hub/node: make a hub on a canvas.  Now every node you create on that 
> canvas or subcanvas belongs to that hub.  If you need more than one, 
> give them names.
> $0: prepend a string with this to make a special name that is unique 
> to a canvas and its subpatches (but not abstractions created in 
> either).  The dollarsign variable will be filled in at the time the 
> patch is created, and given a unique value in the running Pd 
> instance.  If you want a name inside an abstraction to share the $0 
> with its parent, just send $0 as an abstraction argument, then use the 
> corresponding argument number inside the abstraction to retrieve the 
> value of the parent $0.
> I mean, if you can solve $0 in message boxes in a few hours or so then 
> go ahead and do it.  But if it brings up any

Not hours, but rather minutes. That is, unless I am missing something... 
Still not sure, if I fully understood Miller's explanation (see my 

> issues that require workarounds I think the time would be better spent 
> on building out more hub/node infrastructure.  (And they don't 
> necessarily need to have that name, I'm just using it as a placeholder.)
> Btw-- I just heard yesterday from someone using Max/MSP about 
> something like using a "#0-" prefixes to hack local scope for receive 
> symbols.  Is this still the case there, too?

Very much so.

> -Jonathan
> On Wednesday, September 10, 2014 1:08 PM, Ivica Bukvic <ico at vt.edu> wrote:
> What about for instance arrays that should maintain scope inside a 
> specific abstraction so that you can have multiple independent 
> abstractions? $0 is very useful IMHO and is also necessary to stay due 
> to backwards compatibility concerns. Therefore, I think the discussion 
> should be limited to a simple yes or no for $0 substitution inside a 
> message as it does not introduce a myriad of other questions.
> Having message recognize it as such (the code already seeks to resolve 
> dollarzero but fails because the canvas was not set as current which 
> should be a simple addition of a couple of lines of code) makes sense 
> even if the only benefit is not having to do [$0] or what you are 
> suggesting, namely [zerofy-me]. It is also worth noting that there is 
> no reason why the two could not coexist.
> Yet, as it stands right now, $0, contrary to what has been already 
> said in both threads on this topic, is an anomaly inside a message box 
> and behaves like nothing else anywhere else in the code and as such 
> this should be a no-brainer fix, just like having a trigger with 
> static values, like [t 0 f 1] for opening a gate, passing a value, and 
> then immediately closing it. This is what pd-l2ork does (and so does 
> Max). So, rather than putting redundant messages with static values 
> below the [t b] outlet, one object solves it all. To me this is the 
> same situation where message can do it all, and if that makes my 
> patching quicker, I am all for it.
> On Sep 10, 2014 12:48 PM, "Jonathan Wilkes" <jancsika at yahoo.com> wrote:
>     Two things:
>     1) the lack of "$0" in messages is only a symptom of a bigger
>     problem with scope of binding symbols in Pd.  I'd rather see new
>     objects (or wrapper objects) that handle scope in a sensible
>     manner which doesn't require typing "$0-" at all.  There's already
>     no need for $0 in your preset_hub/node design.  Why not extend the
>     hub/node idea and get rid of the need for $0 completely?
>     [hub]/[node] = [send]/[receive]
>     [hub~]/[node~] = [throw~]/[catch~]
>     etc.
>     2) On a more superficial note, isn't the problem that Pd doesn't
>     store stray "\n" characters in message boxes?  The only time I can
>     think of when one would have a real desire for $0 in a message box
>     is when initializing a bunch of receivers:
>     [; $0-foo 1;
>     $0-bar 2;
>     $0-flub 3;(
>     But if the box stored "\n" you could get the same clean format
>     with commas:
>     [foo 1,
>     bar 2,
>     flub 3(
>     |
>     [zerofy-me] <- add a "$0-" to the selector
>     | |
>     [send]
>     No ugly zeros, no leading semi-colon, everybody wins!
>     -Jonathan
>     On Wednesday, September 10, 2014 2:27 AM, Ivica Bukvic
>     <ico at vt.edu> wrote:
>     On Sep 10, 2014 1:17 AM, "Chris McCormick" <chris at mccormick.cx> wrote:
>     >
>     > Hi Ivica,
>     >
>     > On 10/09/14 04:19, Ivica Ico Bukvic wrote:
>     > > Yet, I wonder why message shouldn't be able to pre-parse $0
>     into a valid
>     > > dollarzero (canvas instance), when there will never be a
>     message one
>     > >
>     > > Thoughts?
>     >
>     > There has been a lot of discussion regarding this over the years
>     which
>     > might be good to read to get an idea on the different
>     > philosophical/language design issues:
>     >
>     >
>     <http://comments.gmane.org/gmane.comp.multimedia.puredata.general/56365>
>     Thanks, Chris, for bringing this to my attention. Since one of
>     Miller's core ideas behind pd is absolute backwards compatibility,
>     most of alternatives suggested in that thread would cause
>     unacceptable breakage with backwards compatibility or a really
>     kludge workaround for the support of legacy patches. It seems to
>     me Phil really has a point I completely agree with. FWIW, I am
>     looking to implement this in pd-l2ork and as soon as I get a
>     better idea about the recursion Miller mentioned and how to
>     circumvent it, it should find its way into pd-l2ork's source.
>     Best,
>     Ico
>     >
>     > Cheers,
>     >
>     > Chris.
>     >
>     > --
>     > http://mccormick.cx/
>     _______________________________________________
>     Pd-list at lists.iem.at mailing list
>     UNSUBSCRIBE and account-management ->
>     http://lists.puredata.info/listinfo/pd-list

Ivica Ico Bukvic, D.M.A.
Associate Professor
Computer Music
ICAT Senior Fellow
Virginia Tech
School of Performing Arts -- 0141
Blacksburg, VA 24061
(540) 231-6139
ico at vt.edu

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20140912/ea82fe42/attachment-0001.html>

More information about the Pd-list mailing list