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
response).
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 <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
--
Ivica Ico Bukvic, D.M.A.
Associate Professor
Computer Music
ICAT Senior Fellow
DISIS, L2Ork
Virginia Tech
School of Performing Arts -- 0141
Blacksburg, VA 24061
(540) 231-6139
i...@vt.edu
www.performingarts.vt.edu
disis.music.vt.edu
l2ork.music.vt.edu
_______________________________________________
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
