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" <[email protected]> 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 <[email protected]> > wrote: > > > > On Sep 10, 2014 1:17 AM, "Chris McCormick" <[email protected]> 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/ > > _______________________________________________ > [email protected] mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list > > >
_______________________________________________ Pd-dev mailing list [email protected] http://lists.puredata.info/listinfo/pd-dev
