Someone could write their own message box object and make it do
whatever they want. Then you have both: a new interface and backwards
compatibility. The message box could just be a GUI object like any
other, there is nothing inherently unique about it.
.hc
On Nov 13, 2009, at 6:50 PM, Roman Haefeli wrote:
Finally, we agree. I also think, that using $ twice is confusing, when
the uses are so different.
Personally, i wouldn't mind, if Pd would be changed instantaneously
while breaking backwards compatibility. But i don't think, that it is
realistic.
roman
On Fri, 2009-11-13 at 13:16 -0800, Phil Stone wrote:
Matt Barber wrote:
I am saying two things:
1) Without $0 or something similar, the only way to guarantee
similar
locality would be through use of $1 or $n -- you would have to
manually give each instance an instance number. Sometimes you even
want to be able to group instances in the way you suggested. I'm
not
sure of the history of Pd, but if $0 was implemented after
abstractions with arguments, then manually assigning locality was
probably necessary.
2) Sometimes $0 NEEDS to be inherited (probably as $1 or some
such) by
various helper abstractions within a larger, higher-functioning
abstraction. This is especially the case with dynamic patching --
imagine, say, a "bell synthesis" patch using a dynamically created
bank of enveloped oscillator abstractions. In that case, you'd want
each oscillator abstraction to [throw~] to the same [catch~] within
the parent "instrument" abstraction. To do this, you could have
[catch~ $0-out] within the parent, and [throw $1-out] within each
child, while passing the parent's $0 to the children.
So all I'm saying is that $1-$n often plays a really important
role in
locality, in addition to a number of other things, and to me it
seems
almost natural to use $0 as an analogy for this role.
Good points, all.
I personally
love the idea of using $0 as the selector of the abstraction -- its
name or filename, and $$ as its ID, but too late for that now.
I can't disagree with this, either. Though, in the spirit of wishful
thinking, I'll go it one further: abstraction arguments would ideally
have a different form than message arguments. E.g. #0...#n for
message
args., and $0...$n for abstraction args. (or, the other way around,
whatever)... Then (and only then, I think) would this discussion
not be
_______________________________________________
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
----------------------------------------------------------------------------
"[T]he greatest purveyor of violence in the world today [is] my own
government." - Martin Luther King, Jr.
_______________________________________________
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
