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 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?
-Jonathan
On Wednesday, September 10, 2014 1:08 PM, Ivica Bukvic <i...@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" <jancs...@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 <i...@vt.edu> wrote:
>
>
>
>
>On Sep 10, 2014 1:17 AM, "Chris McCormick" <ch...@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@lists.iem.at mailing list
>UNSUBSCRIBE and account-management ->
>http://lists.puredata.info/listinfo/pd-list
>
>
>
_______________________________________________
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
