<div dir="ltr">not confusing, thanks</div><div class="gmail_extra"><br><br><div class="gmail_quote">2014-04-03 19:54 GMT-03:00 Roman Haefeli <span dir="ltr"><<a href="mailto:reduzent@gmail.com" target="_blank">reduzent@gmail.com</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">On Don, 2014-04-03 at 18:32 -0300, Alexandre Torres Porres wrote:<br>
> > Wow, you keep beating that horse after its dead<br>
> > for quite a while by now<br>
><br>
><br>
> > I don't think this debate is going lead anywhere<br>
><br>
><br>
> please, cope with my lack of knowledge in computer science/languages<br>
> jargons.<br>
<br>
</div>I'm sorry. I sure will (though I don't feel I have in any way less of a<br>
lack of knowledge). Actually, I don't have any computer science<br>
background myself.<br>
<div class=""><br>
> All I'm doing is asking to learn more about it and get what you guys<br>
> mean. I'm not debating, since I'm even stating I couldn't do it when I<br>
> say I probably won't be able to grasp all the details and will just<br>
> take the word for it...<br>
<br>
<br>
<br>
<br>
> So relax, you keep misjudging before reading more carefully. I'm not<br>
> looking for a debate, and I'm also saying I'm cool with Pd's<br>
> workaround myself, so there's no personal frustration. As I said, I'm<br>
> not even thinking about me as my concerns come from luring people into<br>
> using Pd, while I'm already sold for it.<br>
><br>
><br>
> Anyway, having said that, I'd appreciate if anyone could help me<br>
> understand Pd's structure and developing issues.<br>
<br>
</div>I think I can't answer that.<br>
<div class=""><br>
> For instance, I don't think I understand what "inconsistencies" mean<br>
> in this context.<br>
<br>
</div>I try to explain some more. The confusion probably comes from the fact,<br>
that a similar looking syntax is used for two relatively different<br>
things in Pd. A $1 in an object box is substituted by the first argument<br>
I give to the parent abstraction. If I create [myabs 0.3] and myabs<br>
contains an [f $1], the value of $1 actually is '0.3'. If I have a<br>
message box [bla $1( in the same abstraction [myabs], we actually don't<br>
know yet what the value of this $1 is. Only when we send message to [bla<br>
$1( we know what the value of $1.<br>
<br>
[1.7(<br>
|<br>
[bla $1(<br>
<br>
When I click the [1.7( message box, we know that the $1 in [bla $1( is<br>
going to be substituted by 1.7. So far, so good.<br>
<br>
We now have encountered two different $1s in the same abstraction. Once<br>
it got substituted by 0.3 and once by 1.7, although both are written $1.<br>
Confusing, isn't it?<br>
<br>
I know that is nothing new to you at all as you most likely have used<br>
dollar variables in both ways already. What I am trying to say is that a<br>
$1 in a message box [bla $1( is a different animal from a $1 in an<br>
object box [f $1]. Pd could have been designed to make this distinction<br>
more explicit. It could have used # variables for message boxes and $<br>
variables for object boxes. Then we would be able to do both with<br>
message boxes, namely expanding to a parent's argument AND expanding to<br>
an element of the incoming message, depending on whether we use the # or<br>
the $ syntax.<br>
<br>
[1.7(<br>
|<br>
[bla #1(<br>
<br>
In our hypothetical Pd, #1 would be substituted by '1.7' as soon as we<br>
click the [1.7( message box (as does $1 in the real Pd). Clicking on<br>
[1.7( would output 'bla 1.7'.<br>
<br>
[1.7(<br>
|<br>
[bla $1(<br>
<br>
In our hypothetical Pd, $1 would hold the value of the first argument<br>
given to the parent abstraction [myabs 0.3], in our example '0.3'.<br>
Clicking the [1.7( message box would output a message 'bla 0.3'.<br>
However, there is no such thing in the real Pd (yet).<br>
<br>
In the real Pd, the $1 in the message box works totally differently from<br>
the $1 in the object box. The canvas local-ID unique to each instance of<br>
a .pd file (abstraction or patch) can be considered as an argument to<br>
that abstraction or patch. Thus it can easily be accessed by $0 in<br>
object boxes.<br>
<br>
When you propose that $0s in message boxes are substituted by the<br>
canvas-local ID, then you want the function of the dollar variables to<br>
be different depending on what number follows the dollar sign. You want<br>
$0 to access an argument given to the parent, but $1 to be substituted<br>
by the first element of the incoming message. That is where the<br>
inconsistency happens: Why should the function be different based on the<br>
value I put after the dollar sign?<br>
<br>
In our hypothetical Pd, this would be a non-issue. You wouldn't expect a<br>
#0 in message box to get substituted by the canvas-local ID. You would<br>
use $0 for that. In the real Pd, we unfortunately don't have direct<br>
access to the arguments of the parent from message boxes. When you ask<br>
"Why can't a $0 in a message box be substituted by the canvas-local ID",<br>
then you also should ask "Why isn't a $1 in message box substituted by<br>
the first argument given to the parent?" The answer is that this is the<br>
way Pd is designed.<br>
<br>
I'd prefer our hypothetical Pd, if it would exist. However, switching<br>
from today's Pd to our hypothetical Pd would surely break compatibility,<br>
which makes its introduction a bit less likely. Finally, I don't see any<br>
other concise solution than our hypothetical Pd for the<br>
$0-in-message-boxes problem.<br>
<br>
I hope I didn't cause even more confusion.<br>
<span class="HOEnZb"><font color="#888888"><br>
Roman<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
<br>
<br>
> 2014-04-03 17:03 GMT-03:00 Roman Haefeli <<a href="mailto:reduzent@gmail.com">reduzent@gmail.com</a>>:<br>
> On Don, 2014-04-03 at 16:13 -0300, Alexandre Torres Porres<br>
> wrote:<br>
> > thanks for explaining it all<br>
> ><br>
> ><br>
> > > imagine trying to design something like that<br>
> > > which is also backwards compatible with the<br>
> > > crude namespacing tools that already exist in Pd.<br>
> > > It's not possible<br>
> ><br>
> ><br>
> > ok, here's where I'm a bit confuse. You're not saying it'd<br>
> be<br>
> > impossible to make messages inherit the $0 value, are you?<br>
><br>
><br>
> Wow, you keep beating that horse after its dead for quite a<br>
> while by<br>
> now. It is _not_at_all_ about technical difficulties (probably<br>
> it is<br>
> indeed difficult, I don't really know). It's about breaking<br>
> consistency.<br>
> Expanding arguments of the parent is different from expanding<br>
> to<br>
> elements of incoming messages.<br>
><br>
> While I understand your frustration to some degree, I don't<br>
> think this<br>
> debate is going lead anywhere, simply because of that fact<br>
> that I don't<br>
> believe any dev will deliberately introduce inconsistencies<br>
> just for the<br>
> sake of convenience. And yes, I understand the convenience of<br>
> $0<br>
> expanding to the canvas-local ID and yes, it would probably<br>
> make<br>
> patching simpler. I am very much with you in this respect.<br>
><br>
> Roman<br>
><br>
><br>
><br>
><br>
> _______________________________________________<br>
> <a href="mailto:Pd-list@iem.at">Pd-list@iem.at</a> mailing list<br>
> UNSUBSCRIBE and account-management -><br>
> <a href="http://lists.puredata.info/listinfo/pd-list" target="_blank">http://lists.puredata.info/listinfo/pd-list</a><br>
><br>
><br>
><br>
<br>
<br>
<br>
_______________________________________________<br>
<a href="mailto:Pd-list@iem.at">Pd-list@iem.at</a> mailing list<br>
UNSUBSCRIBE and account-management -> <a href="http://lists.puredata.info/listinfo/pd-list" target="_blank">http://lists.puredata.info/listinfo/pd-list</a><br>
</div></div></blockquote></div><br></div>