On Fre, 2014-09-12 at 00:30 -0400, Ivica Ico Bukvic wrote:
On 9/10/2014 2:21 PM, Miller Puckette wrote:
A deeper question bothers me: what about $1, etc, too? What if we're in an abstraction and want to 'speak' to $0 in our calling patch? THe usual way of doing that is for the calling patch to instantiate the abstraction with $0 as an argument. Then the abstraction itself can access it as, say, $1. But that makes me think we need a way for the message box to be able to access $1 as well as $0.
It seems like this should either be something syntactic in messages themselves (that could have deep repercussions as that is at the very heart of everything), or else, perhaps, some kind of "properties" kludge, or perhaps (hopefully) there's a better way I haven't thought of.
This sounds like an interesting development but I am not sure if it negates the immediate benefit of parsing $0 inside a message.
Chiming late here and I also might don't grasp the whole extent of the current discussion, so please excuse me when I repeat things.
While the topic arises every now and then, I fail to understand how people seem to naturally want $0 in message boxes. It's not that I don't see how it would come in handy. It certainly would have saved me a lot of patching. However, dollar variables in object arguments are totally different animals from dollar variables in message boxes. While in objects they access arguments given to the parent, they are used in message boxes to access a specific element of the incoming message. Why should a $0 in a message box access the unique identifier of the parent, but all other dollar variables an element of the incoming message? Wanting $0 (as proposed!) in message boxes is actually wanting totally different functionality depending on the variable name. Why are people only complaining about a missing $0, but not about a missing $3? If I want to access the third argument given to the parent in a message box, I need to use the same kludge ([list append $3]-[$1( ) I have to use in order to access $0. What is the difference? Ah yes, $3 already has a meaning in message boxes, while $0 doesn't. Ok, $0 hasn't been assigned a meaning yet, so let's give it a totally odd meaning. (excuse the snarky tone).
In (my) ideal Pd world, message boxes would be able to access both, the arguments given to the parent and the elements of the incoming message. Since they are different things, I'd propose two different variable prefixes, $ for arguments of the parent and # (or whatsoever) for elements of the incoming list. Then we wouldn't only have $0 in message boxes, but $3 from my example above would work as well. #0 would give you the selector of the incoming message (that is also something that currently cannot be accessed directly).
Of course, this would _totally_ break backwards compatibility. Also I don't know what technical implications such an implementation would come with. Rationale trumps handiness, so personally I rather opt for breaking backwards compatibility than for a kludge that still wouldn't make sense in a hundred years when people would ask themselves: "What does $0 mean in a message box? Ah yes, it is special ... "
Personally, I even prefer the status quo to the proposed use of $0. It is cumbersome, admittedly, but I'd rather miss a feature than using a feature that fully breaks the logic of the whole.
Roman
p.s. I may sound as I'd care a lot about the future of $0 in message boxes. Actually, I do not so much. I certainly could live with the proposed use of $0 in msg boxes. I'd consider it a kludge, nevertheless.