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:
- 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.
- 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.