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@yahoo.com wrote:
Two things:
- 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.
- 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@vt.edu wrote:
On Sep 10, 2014 1:17 AM, "Chris McCormick" chris@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.
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list